On 02/24/2015 11:18 PM, John Rose wrote: > My bottom line: I think we should use the internal HotSpot > API bytes.hpp by surfacing relevant parts of it up into Unsafe. > (One thing feels wrong about bytes.hpp: It insists that big-endian > is the norm for unaligned access. This is simply a legacy of its > origin, for classfile and bytecode parsing.) > > Looking at the various platform code for bytes.hpp, I suppose > one could argue that there are just two cases of interest: > A single instruction (x86/arm) and a complicated 4-way > switch (sparc/ppc). Those could be represented in Java > code as you suggest, at the cost of some duplication. > For special platforms which use a third idiom, the intrinsics > could be adjusted.
OK. > Distinct big and little endian access modes are also available > on some machines, such as SPARC (ASI_LITTLE, etc.). > But I do *not* believe that this capability should be surfaced > as distinct intrinsics in Unsafe. Many cpus and source bases > deal with endian-matching simply by adjoining a separate > "byte swap" operation to the memory access. In Java, > this is already an intrinsic, {Long,Integer,...}.reverseBytes. > And SPARC already optimizes some compositions of > byte reversal and memory access to its special ASI_LITTLE > instructions. > > My second bottom line: Don't multiply endian options. > Use reverseBytes calls instead. OK. > Suggestion: Have getIntUnaligned take an optional boolean > parameter, which is "bigEndian" (since that's relatively exceptional). > An extra line of code can conditionally swap the bytes, taking > both the flag and the platform into account. Default value of the > boolean is whatever is natural to the platform. If you specifically > want Java's big-endian order, you specify true, etc. OK, I'll look at that. Andrew.