Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ensure that the software supports big-endian hardware #5

Open
lemire opened this issue Oct 3, 2017 · 10 comments
Open

Ensure that the software supports big-endian hardware #5

lemire opened this issue Oct 3, 2017 · 10 comments

Comments

@lemire
Copy link
Member

lemire commented Oct 3, 2017

Currently, the code is only tested on little-endian hardware. We would need to run tests and to flip byte order (to preserve interoperability) on big-endian hardware.

@lemire lemire changed the title Ensure that the software support big-endian hardware Ensure that the software supports big-endian hardware Oct 3, 2017
@marshallpierce
Copy link

Perhaps qemu would be a good way to do this? I used https://translatedcode.wordpress.com/2016/11/03/installing-debian-on-qemus-32-bit-arm-virt-board/ a while back when I needed to test something on ARM (and now there is an updated 64-bit version). I'm not sure how good qemu's support for SIMD extensions is, but even if performance isn't representative perhaps we could at least test for correctness of a hypothetical NEON implementation.

@lemire
Copy link
Member Author

lemire commented Oct 3, 2017

The ARM-based systems I work with are little-endian by default. iOS is certainly little endian. I actually don't have access to a little-endian system.

Please see this other issue which is more relevant:

Port to ARM NEON (aarch64)
#6

@marshallpierce
Copy link

I should have been more clear -- I didn't mean that qemu was only useful for ARM, though I definitely did give that impression... Anyway qemu supports many architectures.

@lemire
Copy link
Member Author

lemire commented Oct 3, 2017

Yes. QEMU is fantastic software.

From a practical point of view, I am primarily interested in x64 and Aarch64 architectures, and I think that they should be given priority. Such systems are, by default, little endian.

@KWillets
Copy link
Collaborator

One note about shuffles is that we can switch endianness in u32 lanes by setting index ^= 3. So if we were eg retrieving index 0 little-endian we get 3 big-endian. This reverses bytes for any 4-aligned u32.

@outpaddling
Copy link

Ran it on an iMac G5 running FreeBSD 13.0, clang 11.0.1:

===>  Testing for streamvbyte-0.4.1
cd /usr/ports/wip/streamvbyte/work/.build && ./unit
[streamvbyte_decode] code is buggy gap=729
*** Error code 255

The test passes on amd64 and aarch64, both also running FreeBSD 13.

Cheers,

Jason

@lemire
Copy link
Member Author

lemire commented Aug 12, 2021

@outpaddling

That's a power processor, right? Do we support power processors?

I am impressed that it is building at all... ?

Anyhow, yeah, it is not going to work right now on big endian systems. I'll add a note to the README.

@lemire
Copy link
Member Author

lemire commented Aug 13, 2021

@outpaddling The README said...

It assumes a recent Intel processor (e.g., haswell or better, though we provide runtime dispatching for compatibility with legacy systems) or an ARM processor with NEON instructions (which is almost all of them except for the tiny cores).

I added the following to be explicit:

Big-endian processors are unsupported at this time.

People who need big-endian POWER support are invited to give us a hand.

@outpaddling
Copy link

As the POWER architecture is also moving to LE, not sure anyone will be very motivated at this point. Just gave it a try because I could. If anyone is interested enough to work on the code, I'll be happy to test patches on my iMac G5.

@lemire
Copy link
Member Author

lemire commented Aug 13, 2021

@outpaddling Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants