Ian Lance Taylor wrote:
"PRC" <panruochen@xxxxxxxxx> writes:
The assembly code produced by gcc is:
-----------------------------------------------
800650b0 <loadicon>:
800650b0: 3c048006 lui a0,0x8006
800650b4: 0801964b j 8006592c <SetBufAddr>
800650b8: 24846128 addiu a0,a0,24872
800650bc: 00000000 nop
-----------------------------------------------
The `nop' instruction seems useless at all here.
It's probably caused by requested alignment of the next function.
Note that nop is just the value 0.
To see whether gcc is actually generating the nop, use the
--save-temps option when you compile, and look at the .s file. If you
don't see the nop there, it's coming from something other than gcc.
My argument here is that inserting padding should be done by the linker
not by the compiler/assembler. The only thing the compiler/assembler
should provide in the object code is a padding hint. The hint should
also be graded from "weak hint" to "strong hint" to "mandatory
hint/requirement".
Where a "weak hint" is used when no explicit padding requirement has
been set by the programmer, we're just getting the best practice padding
offer by the compiler for the architecture. At the moment we're forced
to accept this down our throats because the stupid compiler/assembler
forced "nop" instructions onto the tail of object code, once its in
.text its set in stone.
Where a "strong hint" is what a programmer would get if he specified a
hint but this maybe overwritten during linking and would not cause a
linking error to occur.
Where a "mandatory hint/requirement" is what a programmer would specify
where the linking process must error if the padding requirement could
not be met.
I would go so far to say that padding between function/blocks inside
.text should also emit hint information to allow the linker to strip and
reorder code within objects. It would need to record the nature of the
padding (i.e. the reason it was inserted, intra-function-padding,
end-of-object-padding, pre-variable-alignment-padding,
post-variable-alignment-padding, etc...).
Maybe this information could be added to the reloc table, offset,
length, strength-of-padding, reason-of-padding.
All padding (or the minimum amount of padding) that can not be removed
for fear of generating alignment exception is not considered padding for
the purpose of this email. That type of padding has a genuine purpose
to ensure valid and correct execution at runtime. It is only the
extraneous padding that is inserted to improve performance can could be
removed from the target architecture without causing runtime exceptions
to occur.
At some future date it would be nice if the linker could re-order object
code and sub-blocks in object code and all variables so that the most
compact use of memory was possible, or the most compact .text segment
was possible in cases where we really do not care about the performance
hit but we do care about the overall code size. This leads into having
a runtime profiler take a look at the usage of your application and
re-order everything it can to make the memory foot print smaller and the
locality of variables/code better.
Darryl
