Darryl Miles <darryl-mailinglists@xxxxxxxxxxxx> writes: > 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". You need to look at the .s file to see whether the nop is coming from the compiler or not. You didn't say whether you have done that or not. > 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. So, change the compiler to do what you want. > 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 quite a bit of work, but the source code is there if you want to do it. > 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. Sounds good. Go for it. Ian
