Big-endian mode supported for Raspberry Pi with bootable images available(mail-index.netbsd.org)
mail-index.netbsd.org
Big-endian mode supported for Raspberry Pi with bootable images available
https://mail-index.netbsd.org/port-arm/2020/12/03/msg007117.html
28 comments
On some archs (like POWER), backwards compat with legacy applications is a motivator.
Here, well, I suspect the real primary motivation is "cuz we can!/it's cool!" and the novelty of doing it.
On POWER8/9 where we have both big and little endian, there are people who insist on using big endian with a near religious fervour. The best rationalization I've heard is it tends to break badly written code (little endian is more friendly to misaligned casts), but again, I suspect it's just cuz it's cool and just that much more "unusual".
Here, well, I suspect the real primary motivation is "cuz we can!/it's cool!" and the novelty of doing it.
On POWER8/9 where we have both big and little endian, there are people who insist on using big endian with a near religious fervour. The best rationalization I've heard is it tends to break badly written code (little endian is more friendly to misaligned casts), but again, I suspect it's just cuz it's cool and just that much more "unusual".
Yeah, this is a thing. I have an UltraSparc laptop and was excited when I discovered that a bug I had in a little program was endian related after finding a newsgroup post of a similar problem from about 20 years before.
If that's true we're not too far off from where the idea comes from: religious wars over which side you should start peeling a hard boiled egg.
I like to compile an app for a big endian architecture and run its test suite to catch any endian-dependence bugs.
Now, if you don’t have an actual need to port the app to a big endian architecture, maybe eliminating endianness bugs is just pursuing theoretical purity without any practical benefit. But if we are talking about a hobby project (as opposed to work), what’s wrong with that? It’s a good learning experience anyway. And maybe one day you really will need to port something to something big endian, and now you’ll know how.
Like Solaris SPARC (pretty dead I think), or AIX or IBM i PASE or IBM Z (none of which are dead yet, but all smaller than they used to be)
Now, if you don’t have an actual need to port the app to a big endian architecture, maybe eliminating endianness bugs is just pursuing theoretical purity without any practical benefit. But if we are talking about a hobby project (as opposed to work), what’s wrong with that? It’s a good learning experience anyway. And maybe one day you really will need to port something to something big endian, and now you’ll know how.
Like Solaris SPARC (pretty dead I think), or AIX or IBM i PASE or IBM Z (none of which are dead yet, but all smaller than they used to be)
> Now, if you don’t have an actual need to port the app to a big endian architecture, maybe eliminating endianness bugs is just pursuing theoretical purity without any practical benefit. But if we are talking about a hobby project (as opposed to work), what’s wrong with that?
I like that idea. NetBSD focuses heavily on portability, and using less common architectures during testing should help ironing out weird bugs that would otherwise affect portability.
I like that idea. NetBSD focuses heavily on portability, and using less common architectures during testing should help ironing out weird bugs that would otherwise affect portability.
> Like Solaris SPARC (pretty dead I think)
SPARC is supposedly alive under the OpenSPARC project (https://en.wikipedia.org/wiki/OpenSPARC).
I think the market share is pretty thin, though.
However, given that Oracle is involved (https://www.oracle.com/servers/technologies/opensparc.html) I'd stay as far as I can from it.
SPARC is supposedly alive under the OpenSPARC project (https://en.wikipedia.org/wiki/OpenSPARC).
I think the market share is pretty thin, though.
However, given that Oracle is involved (https://www.oracle.com/servers/technologies/opensparc.html) I'd stay as far as I can from it.
> SPARC is supposedly alive under the OpenSPARC project (https://en.wikipedia.org/wiki/OpenSPARC).
My impression is that OpenSPARC is dead. Nobody is working on it any more. (Someone tell me if I'm wrong.)
There is also the open-source SPARC-based LEON radiation-hardened processor line favoured by the European Space Agency, but I think they are looking at moving to RISC-V in the future.
Not only is OpenSPARC dead, I get the impression that "ClosedSPARC" is pretty dead too. After M8, Oracle laid off their CPU design team, there will be no successor to SPARC M8. Fujitsu was going to continue on, but, rumour has it, that they tried to buy SPARC off Oracle but couldn't reach a deal (probably Oracle was asking for too much money) and after that they've decided to move away from SPARC towards ARM. So I doubt their latest SPARC CPU (SPARC64 XII) is going to have a successor either.
POWER/AIX is a different situation from SPARC/Solaris. Unlike Oracle, IBM is continuing to invest and we can expect new iterations in the future.
(I used to work for Oracle, but not in the Systems area, and this isn't any non-public info, just stuff I've heard since I left.)
My impression is that OpenSPARC is dead. Nobody is working on it any more. (Someone tell me if I'm wrong.)
There is also the open-source SPARC-based LEON radiation-hardened processor line favoured by the European Space Agency, but I think they are looking at moving to RISC-V in the future.
Not only is OpenSPARC dead, I get the impression that "ClosedSPARC" is pretty dead too. After M8, Oracle laid off their CPU design team, there will be no successor to SPARC M8. Fujitsu was going to continue on, but, rumour has it, that they tried to buy SPARC off Oracle but couldn't reach a deal (probably Oracle was asking for too much money) and after that they've decided to move away from SPARC towards ARM. So I doubt their latest SPARC CPU (SPARC64 XII) is going to have a successor either.
POWER/AIX is a different situation from SPARC/Solaris. Unlike Oracle, IBM is continuing to invest and we can expect new iterations in the future.
(I used to work for Oracle, but not in the Systems area, and this isn't any non-public info, just stuff I've heard since I left.)
[deleted]
Raspbian used to have a hilarious implementation of memcmp that temporarily switched to big endian mode in a (probably misguided) attempt at speeding things up. Valgrind didn't like this very much: https://bugs.kde.org/show_bug.cgi?id=322935
I don't know enough about the ARM / aarch64 instruction set to know how optimal memcmp()/strcmp() is implemented on ARM / aarch64. However, in the general case, since these comparisons treat earlier bytes as more significant, fast implementation either needs dedicated instructions or wide big-endian unsigned integer comparisons.
A related use case is that if you have structures full of unsigned big-endian integer types, memcmp() will give you the same ordering as numeric comparison of the integers. It's a pretty corner case, but it might be useful for b-tree key comparisons where you have compound keys, say in a database table with a compound primary key.
A related use case is that if you have structures full of unsigned big-endian integer types, memcmp() will give you the same ordering as numeric comparison of the integers. It's a pretty corner case, but it might be useful for b-tree key comparisons where you have compound keys, say in a database table with a compound primary key.
Whether or not the endianness is in your favor, an optimized implementation could still use wide integer comparisons to tear through the bulk of the data quickly. On mismatch, simply fall back to byte-wise to determine the correct ordering.
On a tangent, strcmp seems like it would be difficult to optimize since the length isn't known until the trailing null is found. Does anyone know how it's typically done?
On a tangent, strcmp seems like it would be difficult to optimize since the length isn't known until the trailing null is found. Does anyone know how it's typically done?
I know you asked for strcmp, but the strlen is far better documented on how the null-byte detection works for ARM.
https://lkml.org/lkml/2020/9/14/871
https://github.com/ARM-software/optimized-routines/blob/mast...
https://lkml.org/lkml/2020/9/14/871
https://github.com/ARM-software/optimized-routines/blob/mast...
I see, so the implementations basically read past the end of the string as long as it won't cross a page boundary and cause a memory protection fault. It's technically a buffer overflow, but since the implementations are architecture specific, it's safe to do. I wonder if there are memory sanitizers that would complain about that sort of access?
[deleted]
above 128 bytes, ARM implementations tend to use the NEON/SIMD for memcmp/strcmp so I doubt the endian-ness would matter.
Testing for less common architectures.
Perhaps for emulating some big-endian processors (using QEMU or something similar), there's probably a small speed benefit here?
It'd be too small to notice, and maybe impossible to measure. Emulation performance gets sucked up by MMU emulation, indirect jumps (including function return), and page-crossing jumps. Sometimes memory-mapped IO can also be abnormally bad in emulation.
I am surprised that NetBSD still doesn't support the Pi 4 - given NetBSD's reputation for cross-platform--ness.
And even on earlier Pi's, WiFi and bluetooth doesn't work.
I wonder what the problem is.
And even on earlier Pi's, WiFi and bluetooth doesn't work.
I wonder what the problem is.
I don't have an rpi4 to test, but NetBSD should run fine on them.
Now you can just use generic Aarch64 UEFI images, since the pi 4 has a standards compliant UEFI/ACPI stack aka is "ServerReady"[0], and NetBSD 9 and above supports this machine type [1].
Edit: And for the wifi (and bluetooth) chipset, the gist is "it's a weird proprietary Broadcom chipset behind a somewhat unusual bus (SDIO)". FreeBSD has recently gained nominal support for the bus, eventually a wifi driver will be ported. Another place I've seen a SDIO wifi chipset used like this is the Wii. https://wiki.freebsd.org/SDIO
[0] https://rpi4-uefi.dev/about/
[1] https://www.netbsd.org/releases/formal-9/NetBSD-9.0.html
Now you can just use generic Aarch64 UEFI images, since the pi 4 has a standards compliant UEFI/ACPI stack aka is "ServerReady"[0], and NetBSD 9 and above supports this machine type [1].
Edit: And for the wifi (and bluetooth) chipset, the gist is "it's a weird proprietary Broadcom chipset behind a somewhat unusual bus (SDIO)". FreeBSD has recently gained nominal support for the bus, eventually a wifi driver will be ported. Another place I've seen a SDIO wifi chipset used like this is the Wii. https://wiki.freebsd.org/SDIO
[0] https://rpi4-uefi.dev/about/
[1] https://www.netbsd.org/releases/formal-9/NetBSD-9.0.html
SDIO used to be quite common.
Back when PDAs didn't have WiFi as standard, SDIO was the only way to fit them.
In fact, if I recall correctly my GPD Pocket doodah has SDIO wifi.
The bus isn't unusual, at all.
As for weird broadcom stuff ... I'll give you that, as you're absolutely correct there ;)
Back when PDAs didn't have WiFi as standard, SDIO was the only way to fit them.
In fact, if I recall correctly my GPD Pocket doodah has SDIO wifi.
The bus isn't unusual, at all.
As for weird broadcom stuff ... I'll give you that, as you're absolutely correct there ;)
Lots of people criticizing me for being wrong, but the Raspberry Pi NetBSD page:
https://wiki.netbsd.org/ports/evbarm/raspberry_pi/
(the first result for Googling "netbsd raspberry pi")
says "All board variants earlier than the RPI4 are believed supported, and specific boards known to work are listed."
So if that's wrong... great. But that's what it says.
https://wiki.netbsd.org/ports/evbarm/raspberry_pi/
(the first result for Googling "netbsd raspberry pi")
says "All board variants earlier than the RPI4 are believed supported, and specific boards known to work are listed."
So if that's wrong... great. But that's what it says.
RPI4 support is in current (the future NetBSD 10), not in the last official realease.
The Raspberry Pi 4 has been supported for quite a while. I have a colocated Pi 4 running NetBSD happily. On earlier Pis, Wifi works fine, BTW. I haven't tried bluetooth.
Perhaps the problem is that you forgot to read about it before you posted?
Perhaps the problem is that you forgot to read about it before you posted?
[deleted]
Optimizing for the htons/htonl family of functions in a router/switch is all I can think of, but I'm a network guy.