This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, ARM] Unaligned accesses for packed structures [1/2]
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: julian at codesourcery dot com (Julian Brown)
- Cc: gcc-patches at gcc dot gnu dot org, paul at codesourcery dot com, rearnsha at arm dot com, ramana dot radhakrishnan at linaro dot org (Ramana Radhakrishnan)
- Date: Thu, 1 Sep 2011 16:46:06 +0200 (CEST)
- Subject: Re: [PATCH, ARM] Unaligned accesses for packed structures [1/2]
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.Weigand@de.ibm.com