How the ARM32 Kernel Starts
people.kernel.org
people.kernel.org
But, if you ever find yourself writing an OS, consider running userspace as much as possible near the top of a 64-bit address space. When the first 13 bits of a 64-bit pointer are set, a pointer interpreted as an IEEE-754 double comes out as NaN. The NaNboxing an NuNboxing tricks used by many dynamically typed programming languages become no-ops if all of your userspace pages are in the top 2 petabytes of the address space.
In the world of mobile devices where CPU is battery life, why create a language that is ~10x slower for no user benefit and makes people contemplate about designing the whole OS around its performance issues?
Granted, it's not a common use case. Neither Rust nor OCaml use this space optimization, but they could. OCaml (at least used to, back in the early 2000s) made the maximum tuple/object size smaller in other to have some bits (8 bits, IIRC) to store the variant in the object header. I'm not actually sure how Rust decides how many bits to dedicate to encoding the variant, and I have very little knowledge of GHC internals.
I'm a big fan of Rust (and to some extent, C++), but there's a ton of CPU time being spent on JavaScript execution worldwide.
[1] https://people.kernel.org/linusw/how-the-arm32-kernel-starts
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...