Julian Brown wrote: > The problem is, if we're using little-endian bit numbering for memory > locations in big-endian-bytes mode, we need to define an origin from > which to count "backwards" from. For the current implementation, this > will now be (I believe) one word beyond the base address of the access > in question, which is IMO slightly bizarre, to say the least.
It doesn't seem all that bizarre to me. Conceptually, the extraction (etc.) operation works on an operand of integer type (usually, word sized) in two steps: - read the operand from its storage location, resulting in a plain (conceptual) integer value - extract certain numbered bits from that integer value The first step, reading the operand from the storage location, depends on BYTES_BIG_ENDIAN (as all memory reads do). It does not depend on BITS_BIG_ENDIAN at all. The second step, extracting numbered bits, depends on BITS_BIG_ENDIAN, which provides the link between bit number and its value. This step however does not depend on BYTES_BIG_ENDIAN at all. [However, if BITS_BIG_ENDIAN is true, you need to consider the total size of the operand in order to perform the conversion, since bit 0 then refers to the most-significant bit, and which bit that is depends on the size ... But this still does not depend on *BYTES_BIG_ENDIAN*.] Thus, the two flags can be considered really independent, and any combination is quite well-defined. When actually implementing the extraction, you will of course deviate from that conceptual sequence, e.g. by avoiding to read certain bytes if you know none of the bits in them will end up in the final result. But while this might result in some computations that may not immediately look obvious, in the end this is just an optimization step and doesn't change that the endian flags remain well-defined ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
