Probably just need to build it for x32. I don't think you need to do much, if anything, to a library to build it for x32 (or many modern architectures for that matter).
x32 was a good idea, you save RAM by using smaller pointers, and you save code size by using 64-bit registers less often, and your performance increases as a result. Its only problem was its lack of ability to interact with the non-x32 (native x64) world. Your libraries had to be x32. All your memory had to be within the first 4GB.
Historically, you had things like "far" pointers for situations where you needed two different kinds of pointers. In order to interoperate with 64-bit libraries or system calls, you'd need to have both kinds of pointers available. Then when an x32 application wants to use a 64-bit library, you'd spray "far" annotations over every single pointer in the header file. (But at least that could be automated)
While far pointers seems like a very dirty and unclean solution to the problem, it would allow creating 32-bit programs on an otherwise 64-bit operating system without any thunking or compatibility layers.
I think the reason why it never took off is that it solves a fairly niche problem. It's only useful for performance critical software that's specifically CPU or memory bound, and doesn't need more than 4 GB of memory. It's not useful for anything that's not performance sensitive, or I/O or network bound, or needs to process more than 4 GB of memory, or the developer wants to mmap in large files (so the vast majority of software). I think we've seen that this means it's not very useful in practice by how basically nobody is using it.
I think the reason why it never took off is that it solves a fairly niche problem.
In a way, it came at the wrong time. For a few years in the late '00s, most of us had amd64 hardware but less than 4GB of RAM, and x32 would, in theory, have made most desktops run quite a bit faster.
But it wasn't around until 2011, when we were already well in to the process of moving to 64-bit software. And if it somehow had been available in 2006, we'd have been held back by one or two proprietary applications and the poor state of multilib/multiarch at that time, just as we were with the move amd64.
PerkyPangolin@reddit
Less cruft in kernel is a good thing in my book. Especially cruft that's not being used.
MatchingTurret@reddit
And never was. I can't remember that I have ever seen a tool chain that can build for this target.
wintrmt3@reddit
gcc can
MatchingTurret@reddit
Don't you need corresponding libraries, e.g. a glibc? Compiler is only one piece of the chain.
wintrmt3@reddit
Supported since GLIBC 2.16.
alexforencich@reddit
Probably just need to build it for x32. I don't think you need to do much, if anything, to a library to build it for x32 (or many modern architectures for that matter).
SiteRelEnby@reddit
gcc can do a lot of things, that doesn't mean they're good ideas. (See also: Old versions of OpensSSL)
wintrmt3@reddit
Sure, I have no problem with removing x32 from everything, but the parent commenter did not look very hard for a toolchain that could do it.
MatchingTurret@reddit
A compiler that can output x32 isn't enough, I think. You need a lot of other links in the tool chain.
flatline000@reddit
It is so satisfying to remove code...I wonder how they'll decide who gets to do it?
INITMalcanis@reddit
o7 my old Core2Duo
What an absolute champ that CPU was.
lmpcpedz@reddit
45nm, holy moly
Dwedit@reddit
x32 was a good idea, you save RAM by using smaller pointers, and you save code size by using 64-bit registers less often, and your performance increases as a result. Its only problem was its lack of ability to interact with the non-x32 (native x64) world. Your libraries had to be x32. All your memory had to be within the first 4GB.
Historically, you had things like "far" pointers for situations where you needed two different kinds of pointers. In order to interoperate with 64-bit libraries or system calls, you'd need to have both kinds of pointers available. Then when an x32 application wants to use a 64-bit library, you'd spray "far" annotations over every single pointer in the header file. (But at least that could be automated)
While far pointers seems like a very dirty and unclean solution to the problem, it would allow creating 32-bit programs on an otherwise 64-bit operating system without any thunking or compatibility layers.
ztwizzle@reddit
I think the reason why it never took off is that it solves a fairly niche problem. It's only useful for performance critical software that's specifically CPU or memory bound, and doesn't need more than 4 GB of memory. It's not useful for anything that's not performance sensitive, or I/O or network bound, or needs to process more than 4 GB of memory, or the developer wants to mmap in large files (so the vast majority of software). I think we've seen that this means it's not very useful in practice by how basically nobody is using it.
BCMM@reddit
In a way, it came at the wrong time. For a few years in the late '00s, most of us had amd64 hardware but less than 4GB of RAM, and x32 would, in theory, have made most desktops run quite a bit faster.
But it wasn't around until 2011, when we were already well in to the process of moving to 64-bit software. And if it somehow had been available in 2006, we'd have been held back by one or two proprietary applications and the poor state of multilib/multiarch at that time, just as we were with the move amd64.
SiteRelEnby@reddit
Think you nailed it there. Next to nothing needs <4GB of memory any more, that's barely even enough for the most lightly loaded web browser.
Jean_Luc_Lesmouches@reddit
Don't old games require it?
carlyjb17@reddit
x32 != x86
Jean_Luc_Lesmouches@reddit
Ohhh
anh0516@reddit (OP)
No? This has nothing to do with IA32 emulation, which is here to stay in the kernel.
owenthewizard@reddit
I always thought this was a really cool idea, too bad it never took off.
wRAR_@reddit
I never expected it to become popular, not least because it looked like yet another niche choice (and an incompatible one too)
Flashy_Pollution_996@reddit
RIP legend that nobody ever used 🥹
rebootyourbrainstem@reddit
Makes sense. It was an interesting idea but I don't think anybody is going to mourn it.