Opened 11 years ago
Closed 11 years ago
#8568 closed enhancement (invalid)
Make Haiku endian independent
|Reported by:||jscipione||Owned by:||nobody|
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.
Change History (3)
comment:1 by , 11 years ago
comment:2 by , 11 years ago
"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.
comment:3 by , 11 years ago
|Status:||new → closed|
Replying to jscipione:
Nope, you're misinterpreting his article. The gist is, in Rob's own words:
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:
with how it would be done in Haiku
makes none of his reasons sound very convincing:
Nope, one would read into the appropriate datatype/structure.
Nope, since one would use fixed-width types.
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.
Yep and there's no need to.
I may add:
Again, I disagree. Neither do I consider it advantageous to remove the
*BENDIAN*macros nor, um, all of the byte order macros.