> 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
