Benjamin Herrenschmidt wrote: > No, this loads a 32-bit value (16-bit would be lhz).
My understanding so far (which may be wrong) is that it loads a 32 bit value but it loads it from a memory location that needs to be within +/- 32k of the instriction doing the load. The reason I think this is because when this generated code is compiled I get the error: /tmp/ghc2806_0/ghc2806_1.s:51766:0: Error: operand out of range (0x000000000000adf8 is not between 0xffffffffffff8000 and 0x0000000000007fff) which suggests a 16 bit offset. Btw, this is code generated by the Glasgow Haskell Compiler (GHC). The GHC bug is here: http://hackage.haskell.org/trac/ghc/ticket/7830 > Note: It's more readable if you use the register names, ie: > > lwz %r30, .label - (1b)(%r31) > > The form of lwz is > > lwz dest_reg, offset(address_reg) > > So it will load a 32-bit value from memory at the address contained in > r31 offset by ".label - 1b" which is itself the difference between > two labels, "label", and the first "1:" label before the instruction > > (gcc supports numeric labels that can be referenced with the suffix "b" > for backward and "f" for forward which are handy for small > displacements) Ahh, that would be +/- 32k! > So for example if 1: was the base of the structure and .label a field > in the structure, it would load the 32-bit value of that field for the > structure instance starting at %r31. > > In this case, this looks more like some kind of position-independent > code though. That would definitely make sense. Is there something I could replace this above lwz instruction with that would work for PIC with offsets greater than +/- 32k? Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev