Details

    • Sub-task
    • Resolution: Unresolved
    • P4
    • None
    • None
    • core-libs
    • None

    Description

      At the moment the API and implementation has implicit notion or restriction on native byte order endianness. This needs to be explicit with little/big endian support.

      (Note vector lane endianness of lane order should not be an issue. It's specified to be little endian, i.e. the same order of elements in an array.)

      The areas where endianness impacts are:

      - vector access to byte[]. Currently implicit native endian access is performed. The load/store methods will need to be modified to accept a additional parameter declaring endianness.

      - vector access to ByteBuffer. Currently the methods will throw an exception for a buffer whose order is not native.

      - rebracket (and size constrained reshape). Currently rebracket does not change the bits of the vector in anyway, which should still be the case if native endianness is declared, but we will need an explicit parameter.

      Attachments

        Activity

          People

            Unassigned Unassigned
            psandoz Paul Sandoz
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated: