On 08-Jun-98 email@example.com wrote:
[some code snipped]
> Make the ``noreorder'' an ``reorder''. That way the macro will do the
> right thing for for all CPUs and even produce most efficient code. The
> .set push/pop macros which push/pop the state of all .set modifyable assembler
> options to/from a stack are useful that macros can be used as a black box
> like above.
> For the general case, since we want as few nops to fill delay slots, the
> best thing to do is to leave reordering enabled where possible. There is
> just a few places where reordering really needs to be disabled because the
> assembler wouldn't fill delay slots. I used to disable reordering in
> a lot of older code but it's actually better to make use of the assembler's
> capabilities for better and correct code.
Yes, Ralf, you are absolutely right, this patch was not very well thought out.
the other hand, while beeing on the subject, would this nop make the execution
this code really slower? As far as I know, please correct me if I'm wrong, the
have interlocking pipelines, so the pipeline would stall anyway.
Questions over questions.