Hi Paul, Thanks for taking the time time to provide all that detail. Is that otherwise documented somewhere?
And by the way, what do you call this system call? One other question below. On Tue, Sep 2, 2008 at 2:57 AM, Paul Mackerras <[EMAIL PROTECTED]> wrote: > 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. So I'm not quite comprehending something in the example program. It's changing from big-endian to little-endian, right? So what happens when do_le_switch() returns? (Or is this function simply inlined code?) Above, you just said the stack frames will no longer make sense... (I suppose more generally, I'm wondering: given that the endianess of instructions changes dynamically after this call, it sounds to me like compiled C code would no longer execute after the switch. Clearly, I'm missing something.) Cheers, Michael > > 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. > -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html ------------------------------------------------------------------------- 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
