Make Haiku endian independent

[jscipione]

Rob Pike recently wrote a blog article about how to write endian-independent code. Plan 9 for example has no endian-dependent code despite running on multiple platforms.

Available at the time of this writing here: ​http://commandcenter.blogspot.com/2012/04/byte-order-fallacy.html

The gist of his technique is this, don't be concerned with the endianness of the current host, just pick one, save to your file or write to your stream using that endian, then, on the other side, read the same endian back.

We should be able to eliminate all calls to B_HOST_TO_BENDIAN_INT32 and B_BENDIAN_TO_HOST_INT32. Since we are on x86 right now little endian makes sense to use, but, in the end it really doesn't matter which you choose.

This is a low-priority enhancement, not required, but would be nice to have.

[bonefish]

Replying to jscipione:

The gist of his technique is this, don't be concerned with the endianness of the current host, just pick one, save to your file or write to your stream using that endian, then, on the other side, read the same endian back.

Nope, you're misinterpreting his article. The gist is, in Rob's own words:

There is no reason to ask about local byte order when about to interpret an externally provided byte stream.

We should be able to eliminate all calls to B_HOST_TO_BENDIAN_INT32 and B_BENDIAN_TO_HOST_INT32. Since we are on x86 right now little endian makes sense to use, but, in the end it really doesn't matter which you choose.

I wholeheartedly disagree. We don't control all formats, so we can't just assume they all have the same endianess. And as written above, that is not what Rob aims at. He just doesn't like code that checks the host endianess. And apparently he doesn't seem to have come across preprocessor macros and fixed-width types. Comparing his example for converting a little endian 32 bit number:

i = (data[0]<<0) | (data[1]<<8) | (data[2]<<16) | (data[3]<<24);

with how it would be done in Haiku

i = B_LENDIAN_TO_HOST_INT32(data);

makes none of his reasons sound very convincing:

1. It's more code.

Nope.

2. It assumes integers are addressable at any byte offset; on some machines that's not true.

Nope, one would read into the appropriate datatype/structure.

3. It depends on integers being 32 bits long, or requires more #ifdefs to pick a 32-bit integer type.

Nope, since one would use fixed-width types.

4. It may be a little faster on little-endian machines, but not much, and it's slower on big-endian machines.

It's a no-op on little endian machines. I wouldn't bet on it being slower on big endian machines in general. There are architectures that actually sport an instruction to swap the byte order.

5. If you're using a little-endian machine when you write this, there's no way to test the big-endian code.

Yep and there's no need to.

6. It swaps the bytes, a sure sign of trouble (see below).

Yeah, sure.

I may add:

7. It's more readable, not only because it's shorter, but also because it says what it does.

This is a low-priority enhancement, not required, but would be nice to have.

Again, I disagree. Neither do I consider it advantageous to remove the *BENDIAN* macros nor, um, all of the byte order macros.

[cb88]

"Some architectures (including ARM versions 3 and above, PowerPC, Alpha, SPARC V9, MIPS, PA-RISC and IA-64)" (wikipedia) are bi-endian... I recall reading specifically elsewhere than sparcv9 is however sparcv8 is not. It allows more efficient addressing for devices etc... at least supposedly not sure if any OS uses that support.

Technically, you could have more code hidden there in the macro. Just because you don't see it doesn't mean it isn't there.