This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Byte swapping support
- From: Eric Botcazou <ebotcazou at adacore dot com>
- To: Jürg Billeter <juerg dot billeter at codethink dot co dot uk>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 12 Sep 2017 21:46:07 +0200
- Subject: Re: Byte swapping support
- Authentication-results: sourceware.org; auth=none
- References: <1505208772.3423.7.camel@codethink.co.uk>
> To support applications that assume big-endian memory layout on little-
> endian systems, I'm considering adding support for reversing the
> storage order to GCC.
That was also the goal of the scalar_storage_order attribute.
> In contrast to the existing scalar storage order support for structs, the
> goal is to reverse the storage order for all memory operations to achieve
> maximum compatibility with the behavior on big-endian systems, as far as
> observable by the application.
I presume that you'll well aware of this, but you cannot just reverse the
storage order for any memory operation; for example, an array of 4 chars in C
is stored the same way in big-endian and little-endian order, so you ought not
to do byte swapping when you access it as a whole. So the above sentence must
be read as "to reverse the storage order for all scalar memory operations".
When the scalar_storage_order attribute was designed, discussions lead to the
conclusion that doing the swapping for any scalar memory operation, as opposed
to any access to a scalar within a structure, would not be a significant step
forward to warrant the significantly more complex implementation (or the big
performance penalty if you do things very roughly).
> The plan is to insert byte swapping instructions as part of the RTL
> expansion of GIMPLE assignments that access memory. This would leverage
> code that was added for -fsso-struct, keeping the code simple and
> maintainable.
How do you discriminate scalars stored in native order and scalars stored in
reverse order though? That's the main difficulty of the implementation.
--
Eric Botcazou