diff --git a/_posts/2021-11-30-arm-x86-compatibility.md b/_posts/2021-11-30-arm-x86-compatibility.md new file mode 100644 index 0000000..ab1e9cf --- /dev/null +++ b/_posts/2021-11-30-arm-x86-compatibility.md @@ -0,0 +1,94 @@ +--- +layout: post +title: "Moving Away From The x86" +tags: tech x86 arm kernel bsd +--- + +The world seems to be slowly distancing itself from The x86 in favor of less insane architectures +like ARM and, in some cases, even RISC-V. +Naturally, as someone who has experienced what systems programming on The x86 is like themself +lately, i welcome this shift with open arms (believe me, you really *do not* want to bootstrap an +Intel processor). +However, this does not mean we aren't going to run into major issues. +TL;DR: It would be super cool to have an ARM daughter board that pops into one of your x86 tower's +PCIe slots, and use kernel magic to connect the two for native binary compatibility with multiple +architectures. + +## How We Are Currently Handling It + +A lot of software is just straight up not available on those platforms at the moment, and some of +it never will be, especially the proprietary pieces. +Major software companies typically respond to this by pushing application development towards +interpreted languages like, in the case of Microsoft, C#. +Or they are Apple who, very much in line their tradition, went full bonkers and made +[Rosetta 2](https://en.wikipedia.org/wiki/Rosetta_%28software%29), +an x86 to ARM recompiler. + +Now, the Open Source community isn't nearly affected as much by all of this. +Most software that is written in languages that produce native binaries can just be compiled for +whatever architecture you desire. +And by the nature of being open source, those that can't can at least be adopted by the community. +Not to mention that popular open source kernels, most notably Linux, have been ported to just +about anything with a processor. + +## Lame! + +The two corporate solutions have problems. +Both come with a performance penalty because of the recompilation overhead +(JIT in the case of C#, AOT for Rosetta). +Also, i don't find them particularly cool or exciting. +You know what would be super cool and exciting, though? +Throwing hardware at the problem! +Design a daughter board with an ARM processor that you can stick into one of your existing x86 +tower's PCI Express slots and boom, you're done! +This is also what Apple did way back in 1995 with the +[Power Macintosh 6100/66](https://www.youtube.com/watch?v=9UclHrIIaYA) +by the way, so we know that at least in theory it could work as a viable product. +Now, of course it isn't quite *that* easy, because you will also need at the very least a kernel +that plays along with it. + +## Introducing GayBSD + +If you follow me in the [Fediverse](https://notbird.site/@fef) or on +[Bird Site](https://twitter.com/libfef), +you might have already gotten wind of that thing currently working on called GayBSD +(actually, besides rants about The x86, it's almost exclusively what i post about these days). +It is basically a microkernel that, except for its libc and probably its network stack once that +becomes a thing, is written completely from scratch. +As the BSD in its name suggests, it is supposed to be a BSD adjacent kernel, and i am in fact aiming +for ABI compatibility to FreeBSD in the end. +I was already playing with the thought of making it not only a microkernel but also a distributed +one, and this seems like the ideal use case: native binary compatibility on multiple architectures! +The project is still *extremely* young; as a matter of fact, i haven't even reached user space yet. +So, i have decided to take the opportunity and leave the core design open to such an extension. +It shouldn't even be *that* much extra work, since the nature of being a microkernel requires some +form of abstract IPC protocol anyway. + +But how would this be implemented in practice? +My thought is to handle it kind of similar to the way FreeBSD does ABI compatibility to Linux and +other kernels. +You have a `/compat` directory that essentially contains system roots for the respective native +kernel and architecture (e.g. `/compat/x86-freebsd` for x86 FreeBSD binaries), and when you +`execve` something the kernel automatically `chroot`s into the respective directory first. +The directories inside the sysroot that are supposed to be identical on all architectures (like, +pretty much anything besides program binaries) can just be bindings to the actual system root. + +This leaves us with only one problem: shared memory. +If an ARM program wants to do IPC with an x86 daemon by writing data to shared memory, there might +be a mismatch between the data structure on x86 and ARM. +I don't expect this to be a major problem in most cases, because C's fundamental data types are +(as far as i know) the same length on both platforms, but there might still be architecture specific +quirks in individual programs. +You probably have to try before you can tell for sure. +Another, rather obscure situation would be if the daemon was a JIT compiler, in which case the only +solution would of course be spawning an entirely new daemon for that specific architecture. + +## Conclusion + +In case you haven't noticed, this idea hasn't exactly gotten a lot of time to mature. +Yet. +But i find it a quite interesting concept and hope you do, too. + +If this post got you excited, you are welcome to contribute to GayBSD! +The source is available at . +Just contact me through one of the means in the footer below if you would like to know more.