Slashdot Mirror
Linux Kernel Developers Discuss Dropping x32 Support (phoronix.com)
An anonymous reader shared a report: It was just several years ago that the open-source ecosystem began supporting the x32 ABI, but already kernel developers are talking of potentially deprecating the support and for it to be ultimately removed..
[...] While the x32 support was plumbed through the Linux landscape, it really hasn't been used much. Kernel developers are now discussing the future of the x32 ABI due to the maintenance cost involved in still supporting this code but with minimal users. Linus Torvalds is in favor of sunsetting x32 and many other upstream contributors in favor of seeing it deprecated and removed.
[...] While the x32 support was plumbed through the Linux landscape, it really hasn't been used much. Kernel developers are now discussing the future of the x32 ABI due to the maintenance cost involved in still supporting this code but with minimal users. Linus Torvalds is in favor of sunsetting x32 and many other upstream contributors in favor of seeing it deprecated and removed.
Would it have hurt to include this?
The Linux x32 ABI as a reminder requires x86_64 processors and is engineered to support the modern x86_64 features but with using 32-bit pointers rather than 64-bit pointers. The x32 ABI allows for making use of the additional registers and other features of x86_64 but with just 32-bit pointers in order to provide faster performance when 64-bit pointers are unnecessary.
...except for the fact that this explanation is 25% of the four-paragraph article, and another 25% of it was already in TFS. Oops.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
That's not what the x32 ABI is for.
That's not what x32 is. 32-bit x86 will still be supported.
"x32" is an ABI for x86-64 that uses 32-bit pointers with the x86-64 instruction set for better performance when a large address space is not needed. ;)
It's in the second paragraph in the TFA
"We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
Wrong CPU, nothing to do with 4/586s. From TFA itself:
The Linux x32 ABI as a reminder requires x86_64 processors and is engineered to support the modern x86_64 features but with using 32-bit pointers rather than 64-bit pointers. The x32 ABI allows for making use of the additional registers and other features of x86_64 but with just 32-bit pointers in order to provide faster performance when 64-bit pointers are unnecessary.
While the x32 support was plumbed through the Linux landscape, it really hasn't been used much. Kernel developers are now discussing the future of the x32 ABI due to the maintenance cost involved in still supporting this code but with minimal users.
Comment removed based on user account deletion
It allows access to the extended registers of x86_64 but with 32-bit pointers. It requires an x86_64 processor to be used.
Perhaps you could not be retarded and just know this?
X32 is a stupid version of 64 bit that uses 32-bit pointers.
Never understood who thought this was a good idea.
People who care about memory footprint? Linux is used in some pretty small systems, still. If you have far, far less than 4GB you not only don't need 64-bit addressing, you need to not waste 4 bytes on every pointer.
Why not just use x86? More registers (and x64 has a lot more registers) can make a real performance impact.
Socialism: a lie told by totalitarians and believed by fools.
It looks like you missed a verb there. Either that, or Slashdot has finally come across something everyone on Slashdot can agree is "News for Nerds." One nerd attempting to assassinate a group of nerds certainly meets every possible meaning of "News for Nerds."
An x64 processor is expensive, large, and power-hungry for modern "pretty small systems." If you have far, far less than 4GB, you've probably moved to 32-bit ARM.
I'd say you must be new here if you expect people to RTFA, but your UID is a respectable 4 digits...
Or another way of putting it, his UID can be expressed in 11bits and is therefore obsolete and we should consider dropping support.
Ah damn ok it isn't x86, I was confused...
"Science will win because it works." - Stephen Hawking
I would think it would be fairly limited. The benefit would really only be felt by programs where a large percentage of the total used memory was pointers... so perhaps large graph-analysis applications? Perhaps neural networks, where it could reduce the size of an individual "synapse" from 96 bits (64 bit pointer + 32 bit weight) to 64 bits (32bit pointer+32 bit weight), saving roughly 1/3rd of the total program memory without resorting to index-based access and the associated overhead of pointer addition (though x32 may still incur that overhead behind the scenes - I don't know).
Offhand I can't think of anything else that's going to have a pointer/data ratio high enough for the size of pointers to make much difference.
Hmm, though the other factor is cache page size - you can fit twice as many 32 bit pointers in the same cache page - so for traversing large data trees you could potentially get a significant performance boost by using smaller pointers. Provided of course that you never wanted to deal with more than 4GB of total data.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Don't take the 10% advance away from me! :-/ https://t2sde.org/
Now I see who's downvoting me.
x32 has never been deployed by any known company in any measurable quantities. And yes, Linux kernel architecture do require maintenance. In short your entire comment is invalid. Perhaps, you've mistaken x32 for something else (most ./ readers don't understand the difference between x86 and x32 - the latter is a completely different beast).
Also, no commercial/proprietary software exists for x32.
I also have to not that x32 was created as a sort of experiment. It has gained almost no traction anywhere and it's not really used by anyone aside from Gentoo/LFS lovers.
Whether Al Gore is a conman or not has absolutely no effect on whether humans are causing global warming. Your argument is that the warming over the past few decades is due to natural variability, though you haven't a clue what kind of natural variability you're implicating. I explained the physical processes by which human activity is causing the Earth to warm. Rather than discuss the science, you replied with personal attacks and mostly copied and pasted your previous idiotic post. Most likely, you don't know a thing about how the climate system works, so personal attacks and mindless rhetoric are your tools of choice.
Just so you know, I'm a meteorologist. My field is closely related to climatology, and I have a good understanding of how the climate system works. I've actually run climate and weather models. I've presented my work at professional conferences and published in peer-reviewed journals. I've run numerical weather prediction models like WRF and CM1 on hundreds of cores to simulate processes in the atmosphere. Much of what I do focuses on processes within thunderstorms but I certainly do understand the climate system and have done a portion of my work in that area.
Since you don't provide any scientific arguments that can be discussed, what are your qualifications that merit trusting you about climate change? Please do tell.
Modern memory-constrained systems are not x64, though. They're ARM. The type of memory constraints that x86 systems have are not at the scale that benefits from accessing half a register.
And when you're programming an embedded system that is that memory-constrained, it is perfectly normal to have sections of inline ASM. So that is what you'd do if you actually needed this.
And generally when things are that constrained you're not using linux anyways. That's the real point. People accessing half a register are running Mbed OS or FreeRTOS or something. Before you want this feature, you already switched to ARM, and you probably also then went smaller than linux.