Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8223368

[vector] vector API must carefully limit dependencies on native byte order




      Currently the `Vector::reinterpret` method has a dependency on native byte order. Although it can operate purely within the vector unit, its behavior is documented to be one of two different cases, depending on the organization of the memory of the host platform. This makes the method much less useful: It cannot be used to reorganize vectors in the vector unit unless they are about to be stored into memory. Portability bugs are inevitable.

      - Byte order dependencies should be specified as little-endian, when not related to actual use of host memory.

      - Probably, a lane-wise reverseBytes operation is needed to provide explicit access to big-endian representations, either before the reinterpret, or after, or both.

      - Perhaps, the reverseBytes operation should be defined in terms of a lower-level reinterpret to Vector<Byte>, followed by a standard N-blocked lane reversal Shuffle<Byte> where N is the number of bytes in the original vector, followed by an inverse reinterpret. Such standard shuffles are useful even beyond byte reversal, especially in concert with lane rotation and lane shift shuffles. For example, they can be used to swap lanes by groups.

      - When a vector is loaded or stored to a byte array or a byte buffer, byte order effects must be controllable. A byte order argument seems to be necessary here.

      - When loading or storing float or double values under either potential byte swapping or native byte order, the byte-wise format of the float or double values must be clearly specified as stemming from `floatToIntBits` and its inverse, and likewise `doubleToLongBits`. The "raw" versions of these conversions are probably not desirable, for reasons of portability.




            jrose John Rose
            jrose John Rose
            0 Vote for this issue
            3 Start watching this issue