If you read my previous article on DOS memory models, you may have dismissed everything I wrote as “legacy cruft from the 1990s that nobody cares about any longer”. It's time to see how any of that carried over through the 16-bit to 64-bit evolution.
As you note, it's important to distinguish between code size and data size. In 2003 I posted an article to comp.arch (now contained in https://jlforrest.wordpress.com/2017/03/06/the-forrest-conjecture/) that attempts to point out that even 32 bits is plenty now for code, while something larger than 32 bits is required for data. It wouldn't make sense to have a processor with different data and code sizes, so today's 64 bit code and data processors are a very good workaround.
As I mention in my paper, it's hard to imagine a time when this will no longer be true, assuming programs are written by humans. I have no idea how long it will take for programs to be written by some kind of AI, and what the necessary processor model will have to be then.
You don't even need AI. IL2CPP transpiles C# into C++ and produces HUGE binaries as a result, especially in debug mode. So much that I hit a code segment limit on PS4 once with those. Admittedtly, it's a bit of cheating, as most of this size is taken by debug information embedded in binary, not code itself, which only ever came up to about 900Mb, if I remember correctly, but it's not hard to imagine it growing up further - you just have to use even more generic classes...
No, as I said, it was created by automatic process that transforms code written in C# to C++ (and the result is compiled using usual C++ compiler). My point was it's not even AI, and it's already widely used in production (gamedev).
I believe x32 support was only ever considered experimental, and has been removed from the Linux kernel for a few years now. If you have an older pre-2018 vintage amd64 kernel support can be enabled, and binaries will run assuming you have an appropriate set of libraries for them to link against.
I did run an x32 gentoo for a while as an experiment, and it did use slightly less memory and *some* things were slightly faster while others were slightly slower but the differences were negligible. You also lost the ability to address larger amounts of memory in a single process.
x32 only ever existed because of limitations in x86, if you look at other 32->64 architectures like PPC, MIPS, SPARC or HPPA you could still access the full register set and even perform 64bit calculations from a 32bit binary the only thing you couldn't do is address more memory from a single process. Solaris/Sparc for instance shipped with a 32bit userland, and you could compile 32bit binaries to use features and registers of the newer 64bit UltraSparc chips without requiring a separate 32+ version of all your libraries.
Edit: Just remembering this is not strictly true, IRIX/MIPS had the "o32" and "n32" ABIs, where n32 was the one forward compatible with 64bit cpus.
Also outside of x86, 64bit cpus are "legacy cruft from the 90s"... the 64bit MIPS R4000 came out in 1991, other architectures quickly followed. It was only x86 and ARM which only went 64bit in the 2000s.
As you note, it's important to distinguish between code size and data size. In 2003 I posted an article to comp.arch (now contained in https://jlforrest.wordpress.com/2017/03/06/the-forrest-conjecture/) that attempts to point out that even 32 bits is plenty now for code, while something larger than 32 bits is required for data. It wouldn't make sense to have a processor with different data and code sizes, so today's 64 bit code and data processors are a very good workaround.
As I mention in my paper, it's hard to imagine a time when this will no longer be true, assuming programs are written by humans. I have no idea how long it will take for programs to be written by some kind of AI, and what the necessary processor model will have to be then.
You don't even need AI. IL2CPP transpiles C# into C++ and produces HUGE binaries as a result, especially in debug mode. So much that I hit a code segment limit on PS4 once with those. Admittedtly, it's a bit of cheating, as most of this size is taken by debug information embedded in binary, not code itself, which only ever came up to about 900Mb, if I remember correctly, but it's not hard to imagine it growing up further - you just have to use even more generic classes...
Right. My point is that no human-written code will ever exceed the space of a 32-bit code segment.
That 900Mb you mention (was it really megabits?) is surprisingly large. Was it really created by humans?
As a point of comparison, the vmlinuz on my Fedora 40 workstation system is
16289792 bytes (i.e. 16 MB).
No, as I said, it was created by automatic process that transforms code written in C# to C++ (and the result is compiled using usual C++ compiler). My point was it's not even AI, and it's already widely used in production (gamedev).
I believe x32 support was only ever considered experimental, and has been removed from the Linux kernel for a few years now. If you have an older pre-2018 vintage amd64 kernel support can be enabled, and binaries will run assuming you have an appropriate set of libraries for them to link against.
I did run an x32 gentoo for a while as an experiment, and it did use slightly less memory and *some* things were slightly faster while others were slightly slower but the differences were negligible. You also lost the ability to address larger amounts of memory in a single process.
x32 only ever existed because of limitations in x86, if you look at other 32->64 architectures like PPC, MIPS, SPARC or HPPA you could still access the full register set and even perform 64bit calculations from a 32bit binary the only thing you couldn't do is address more memory from a single process. Solaris/Sparc for instance shipped with a 32bit userland, and you could compile 32bit binaries to use features and registers of the newer 64bit UltraSparc chips without requiring a separate 32+ version of all your libraries.
Edit: Just remembering this is not strictly true, IRIX/MIPS had the "o32" and "n32" ABIs, where n32 was the one forward compatible with 64bit cpus.
Also outside of x86, 64bit cpus are "legacy cruft from the 90s"... the 64bit MIPS R4000 came out in 1991, other architectures quickly followed. It was only x86 and ARM which only went 64bit in the 2000s.
In the x32 binary
mov %eax,%eax
Is that padding or what?
Thanks for your article. I really like it the questions you're opening and the steps you show to look for answers.
Thanks! Glad you liked it.