Michael Kerrisk writes: > In the interests of perhaps documenting this (I don't know Power assembler), > can you provide some more info on this interface, like: > > * What are the settings to enable little/big endian mode? (Or is it > just a toggle, with successive identical calls just switching the mode?)
It's a toggle. > * Does the call return any information about the previous endianess state? No. This is a somewhat unusual system call in that it you can't just call it from normal C code, since it switches the endianness of instruction fetches as well as data loads and stores. This is the way that PowerPC processors that support true little-endian mode work; there is just the one bit that controls the endianness of both instruction and data. (I say "true" little-endian to distinguish it from the "PowerPC little-endian" mode that some earlier processors supported, where the change of endianness was implemented by swizzling the low 3 address bits depending on the size of the access rather than actually byte-swapping the data coming in from memory.) At the moment, POWER6 and the PA6T core from PA Semi are the only 64-bit processors that support true little-endian mode. So to use this system call, you have to set up an instruction sequence in the current endianness, up to the system call instruction for the endian switch, followed by instructions that make sense in the other endianness. You also have to be prepared for the fact that every single datum in memory that's larger than a byte is going to appear to change. So the chain of stack frames will no longer make sense after the call, for instance. This system call is also unusual in that it doesn't return a value in R3 and an error indication in condition register 0 like other system calls. In fact it doesn't affect any registers except for R11 and R12. > (It appears not, but I better check.) If not then how does one determine > the current state? The sequence of bytes in memory for the system call instruction to switch from big endian to little endian is different from the sequence of bytes for the LE to BE switch, because the system call instruction, and every other instruction you execute, has to be in the current endianness. (All instructions are 4 bytes long.) So I don't think there's really any possibility that you could be unaware of the current setting. There is one point where you might be unsure of the current state - immediately after doing the endian-switch system call, if it could have failed because the processor lacks little-endian support or the kernel is too old to support the system call. And of course you can't just use a conditional branch to test whether the system call reported an error because the byte sequence you need to make that conditional branch instruction depends on what endian mode you're in. (That is why I didn't bother making this system call return an error indication in the usual manner.) Fortunately, it turns out that a "b .+12" instruction (branch to the instruction 12 bytes after this one) is a no-op if interpreted in little-endian mode. So one can use that to direct the flow of control one way or the other depending on whether the mode switch happened. > * Is any wrapper support for this interface going into glibc, do you know? I highly doubt it, since it breaks the normal C execution model so completely. You really need to know what you're doing to use it - particularly since we don't have toolchain support for generating little-endian instructions at present. Paul. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
