On 02/25/2015 11:26 AM, Paul Sandoz wrote: > To your point with the current unsigned byte Lexicographic > comparator prototype if i were to modify to use the unaligned access > methods i would want native order and only take the hit of > reversing, if required, if two elements are not equal.
I agree. > Note that code will anyway be modified to use a more general array > mismatch method leveraging the unaligned access methods using native > order (i cannot think of a reason why it not do otherwise). It has to: array elements are stored in the same order regardless of what the hardware does. So byte-swapping does not help here: it'd have to be subword-swapping, which some targets support (AArch64 does) but AFAIK Java doesn't. I would enormously prefer to solve the simpler problem rather than all possible versions of related problems. The model used in bytes.hpp makes sense IMO. The issue of non-native endianness is better handled at a different level from Unsafe in my opinion: that way we can use native-only intrinsics for the most common machines and reverse bytes in the caller. But if the desire is for a full set of native-, big-, and little-endian methods I can do that. Andrew.