🚀 go-pugleaf

Expires:

Sender:

Followup-To:


>> In article <299@vaxb.calgary.UUCP>, radford@calgary.UUCP (Radford
>> Neal) writes:
>> > Something I've wondered about:
>> > 
>> > On RISC machines with delayed branches, who does the instruction
>> > rearrangement that tries to put useful instructions after the branch?
>> > 

To which steve@jplgodo.UUCP replies:
>> An optimizing assembler?  What a disaster that would be.  I  want
>> assemblers to leave my code exactly as I wrote it.

This position assumes that there is a point in writing code in the
lowest levels of a RISC architecture and that strict adherence to
the letter of such code is desirable.

Although both points have some strength when applied to standard
machines, they both get weakened with more complicated cases (for
instance, RISCs or machines with strange synchronization
requirements).   The Assemblers for those machines are designed
mainly as postprocessors for compiler output, so they are part of
the compilation process (in Unix terms, they allow you to put your
layout for a.out in a single program, not in each compiler).  Seen
from this perspective, it is not outrageous that those assemblers
take liberties (which might be an option anyway) with their input.

On a slightly different point, there is precedent for assemblers
helping in opcode selection.  Span-dependent jumps and calls, for
instance, can be selected by the assembler, so you don't have to
keep a running location-counter as you code; you just say 'j-or-b
foo' and the assembler decides on a jump or a branch, depending on
how far away foo ends up being.

If you are forced to write code in those assemblers AND YOU WANT
NO-OPS in the delayed branches, I guess you have the right to insist
in keeping that as an option.  Same goes for SIMDs with software
control of the pipeline interlocks, microprogrammable graphics
systems and what-have-you, if the assembler level contains any
weirdness that you might not want to see: let the assembler do some
clean-up, but keep as an option straight code production.
-- 
Cesar Augusto  Quiroz Gonzalez
Department of Computer Science     {allegra|seismo}!rochester!quiroz
University of Rochester            or
Rochester,  NY 14627               quiroz@ROCHESTER