3 ms·

IMO it's a mistake to develop a board that's not capable of running 64 bit ARM code these days. While you might not need the address space capabilities, aarch64

IMO it's a mistake to develop a board that's not capable of running 64 bit ARM code these days. While you might not need the address space capabilities, aarch64 standardizes a lot of things that would otherwise bite you in the ass if you develop software that needs to run on several flavors of ARM. I.e. all 64 bit ARMs have NEON and hard float. And not just any NEON, but NEON specific to 64 bit ARM, with newer instructions. You get a _very_ nice lowest common denominator to code against. Nicer, in some regards, than Intel. This is especially egregious considering that Raspberry Pi 3 _does_ have 64 bit chip, even though they run it in 32 bit mode. I guess what you're really buying in this case is a hardware 4K video decoder.

deaddodo 10y ago
As someone who has done some osdev on the ARM, this is true to a degree. It's similar to ia32 vs amd64. From amd64, you can ensure that SSE exists and guarantee that certain legacy features don't need to be coded around. Plus additional GP registers are always nice and you know they're there (despite usually leaving that to a compiler to manage). With aarch64, you can ensure that VFP3+ and NEON both exist for FPU capabilities and choose between them at your behest (FP accuracy vs speed). You also get a few cryptographic features (AES, a couple SHA's and finite field arithmetic). However, with x86 you're able to use the CPUs (more or less) with feature flags since you can test for features in real-time. ARM doesn't offer this to near the degree (since there is no BIOS/UEFI in most boards), so you either code/compile directly for a certain CPU and it's features or use something like U-Boot/Linux's device tree spec files to hint at a boards feature set. You also have different entry points, clock speeds, memory maps, etc. This is why you see most Linux/FreeBSD/Android releases released per-board vs generic installers like with x86.
- general_ai 10y ago
  Yes, my interest is basically at a level slightly above the OS, not bare metal embedded or OS development per se. And the OS (at least Linux) will tell you which features a given CPU supports. It's just that the variety on the 32-bit side is so enormous, it's hard to be sure of anything. I.e. your particular chip might not even have hardware FP. With aarch64 even the lowest common denominator is better than just about any arm32 (modulo the specialized extra hardware the particular chip might have).
digikata 10y ago
I would caveat that to add if you're planning on running linux, 64-bit in the upscale ARM chips makes a lot more sense. But if you're running in the 'deeply' embedded space, there are plenty of 32bit ARMs (without MMUs) in the -M/-R family that are used for developing bare metal or RTOS that will be around for a long time and the experience will carry forward just fine.

deaddodo 10y ago

As someone who has done some osdev on the ARM, this is true to a degree. It's similar to ia32 vs amd64. From amd64, you can ensure that SSE exists and guarantee that certain legacy features don't need to be coded around. Plus additional GP registers are always nice and you know they're there (despite usually leaving that to a compiler to manage). With aarch64, you can ensure that VFP3+ and NEON both exist for FPU capabilities and choose between them at your behest (FP accuracy vs speed). You also get a few cryptographic features (AES, a couple SHA's and finite field arithmetic). However, with x86 you're able to use the CPUs (more or less) with feature flags since you can test for features in real-time. ARM doesn't offer this to near the degree (since there is no BIOS/UEFI in most boards), so you either code/compile directly for a certain CPU and it's features or use something like U-Boot/Linux's device tree spec files to hint at a boards feature set. You also have different entry points, clock speeds, memory maps, etc. This is why you see most Linux/FreeBSD/Android releases released per-board vs generic installers like with x86.

general_ai 10y ago
Yes, my interest is basically at a level slightly above the OS, not bare metal embedded or OS development per se. And the OS (at least Linux) will tell you which features a given CPU supports. It's just that the variety on the 32-bit side is so enormous, it's hard to be sure of anything. I.e. your particular chip might not even have hardware FP. With aarch64 even the lowest common denominator is better than just about any arm32 (modulo the specialized extra hardware the particular chip might have).

digikata 10y ago

I would caveat that to add if you're planning on running linux, 64-bit in the upscale ARM chips makes a lot more sense. But if you're running in the 'deeply' embedded space, there are plenty of 32bit ARMs (without MMUs) in the -M/-R family that are used for developing bare metal or RTOS that will be around for a long time and the experience will carry forward just fine.