This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Byte swapping support


On Tue, 2017-09-12 at 21:46 +0200, Eric Botcazou wrote:
> > 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".

Yes, I'm aware of this.  Thanks for stating this more clearly.

> 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).

Was this considered significantly more complex because of the need to
discriminate between native and reverse order? Or do you expect similar
complexity even if this is not required (see my comment below)?

> > 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.

I don't. The idea is to reverse scalar storage order for the whole
userspace process and then add byte swapping to the Linux kernel when
accessing userspace memory. This keeps userspace memory consistent
with regards to endianness, which should lead to high compatibility
with big-endian applications. Userspace memory access from the kernel
always uses a small set of helper functions, which should make it
easier to insert byte swapping at appropriate places.

Jürg


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]