Linux Kernel Developers Discuss Dropping x32 Support (phoronix.com) 202
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.
Re: No! (Score:4, Insightful)
That's not what the x32 ABI is for.
Re: (Score:2, Insightful)
Re: No! (Score:5, Informative)
It allows access to the extended registers of x86_64 but with 32-bit pointers. It requires an x86_64 processor to be used.
Re: (Score:2)
Hey Ivan, welcome back!
For today's English lesson, go and look up Ms. and Miss.
Stop complaining about the summary when you don't even understand basic English. Try running it through Google Translate or something.
Re: No! (Score:4, Interesting)
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.
Re: (Score:2)
Not to mention that x32 still lets you use 64-bit native words, etc. for faster computation with the smaller memory footprint.
Re: (Score:2)
Also PC-relative addressing works in x32 mode, and that's a huge gain over i386 for position-independent code (think shared libraries and ASLR). It's supposed to help reduce the size of the working set so you don't thrash the cache as much as you would with 64-bit pointer, size_t etc. Cache miss latency is horrible on modern systems. The trouble is, there are very few libraries built for it, so you pretty much have to build your own userland before you can do anything.
Re: (Score:2, Interesting)
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.
Re: (Score:2)
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 admire your ideal world where management chooses components rationally.
Re: (Score:2)
Just because the BOFH didn't explain their reasons, doesn't mean they were irrational. It only means you're not important enough to know. And the BOFH is probably an engineer.
Re: No! (Score:4, Informative)
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.
Re: (Score:2)
Interesting thread/article here on /. today - refreshing & back to "old-school slashdot" imo (better than POLITICAL or "SJW" articles that have been hitting this place the past year or so now)... apk
Yeah, fewer and fewer real articles between the clickbait, but those few are still interesting.
Re: It's VERY clear Al Gore = hypocrite conman (Score:2)
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
Re: (Score:2, Interesting)
So, yes, human activity is driving the warming over the past few decades. Insult me if you must, but that won't change the physics involved.
You gave a nice middle-school level Earth Science description of how global warming works, but you gave no evidence for this claim. Obviously, human activity affects the climate, the question is: just how much, exactly?
If you look a bit deeper into the science you'll find it's all about feedback loops. The amount of CO2 in our atmosphere wouldn't amount to much warming without positive feedback loops. There are also negative feedback loops, and it's all poorly understood, which is while climate science is
Re: (Score:2)
Regarding the responsibility for the recent warming, I'll offer two hypotheses: man-made greenhouse gases and changes in solar output. If the solar output is the main factor, we would expect to see solar output increase to coincide with the warming. In reality, it's remained steady, if not slightly decreasing. However, the greenhouse gases concentrations continue to increase, and do a better job of explaining the observed warming.
You're familiar with the ice core data from Vostok et al? The clockwork regularity of the 100k year cycle is clearly solar. And yet, 10k years ago the clock broke, and the glaciers did not return. Why not? No one knows, but solar output remaining steady is a glaring anomaly.
The past 10k years of relative climate stability are unique in the past million-ish years that we have data for. Good thing too, as it's what allowed humans to become technological.
To me, the biggest question is where would the cli
Re: (Score:2)
People under severe memory constraints who need to use pointers that take up only half the space? People under severe performance constraints who can't spare the cycles to copy 64-bit pointers or do 64-bit lookups?
Re: (Score:2)
People under severe memory constraints who need to use pointers that take up only half the space? People under severe performance constraints who can't spare the cycles to copy 64-bit pointers or do 64-bit lookups?
Why are said people using a 64-bit CPU in the first place, then? Let them use a 32-bit ARM CPU or something, and stop gimping the x86_64 architecture.
Re: (Score:2)
Because the architecture offers significant enhancements besides 64-bit pointers, and they want those enhancements without having 64-bit pointers for the reasons I stated.
Re: (Score:2)
This should only save space, not cycles. A 64 bit computer takes the same time to do a 64 bit or 32 bit operation. This is all about pointer size.
The same thing exists on 32 bit machines, where it is normal to support both 32 and 16 bit pointers.
Re:No! (Score:5, Informative)
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
Re: (Score:2)
It's in the second paragraph in the TFA ;)
I'd say you must be new here if you expect people to RTFA, but your UID is a respectable 4 digits...
Re:No! (Score:5, Funny)
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.
Re: (Score:1)
We're only talking about dropping support for referencing UID 1135 directly. He can still reference it like everyone else by using the standard UID 0000001135 scheme.
Re: (Score:1)
Re: LMAO - Look @ your "ReAcTioN", lol... apk (Score:1)
Again, you are complaining about users modding you down. This certainly qualifies as complaining:
REPOSTED 2nd time to exhaust the LIMITED abused DOWNMODPOINT of an obviously OBSESSED psychotic LOON that STALKS me constantly & downmods me projecting his MENTAL issues here https://linux.slashdot.org/com... off topic.
Again, that is you complaining. By "take EFFECTIVE ACTION", you mean that you spam your posts that were previously modded down. You've admitted to that multiple times in this story.
It is logical that lots of users, almost certainly a large majority of readers, consider your posts to be of poor quality. That is why you are consistently modded to -1, and why numerous users have asked Slashdot for years to curtail
Re:No! (Score:4, Informative)
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.
musl libc has supported it for years. (Score:1)
As far as I know their support is feature complete, outside of bugs in the toolchain/kernel.
Personally all these 'lets delete xxx feature' discussions and removals is just making the linux kernel LESS interesting, while the major fuckups and bugs in the kernel are mostly in new, stupid, overengineered code that wasn't well thought out to begin with.
x32 from everything I hear has some shortcomings, but at the same time has been the proof of concept for all the other 32 on 64 bit ABI attempts made. Furthermor
x32 does not mean what you think it means (Score:1)
Wikipedia [wikipedia.org]:
It's a 64-bit CPU thing, not a 32-bit CPU thing.
Re: (Score:1)
This isn't about removing x86 32 bit support as far as I can see, it's about removing 32 bit support for 64-bit processors using the x86_64 branch, it's niche and only started appearing in 2012:
details [phoronix.com]
Re: (Score:1)
You mean "x86" architecture, and that's not what this is about. "x32" is a feature of the Linux kernel where an application can run in a 4GB address space with all pointers being only 32 bit wide while still being in x86-64 mode and having access to all of the new instructions.
Re: (Score:1)
A 486 does not support x32.
Re: (Score:3)
Ah damn ok it isn't x86, I was confused...
What is x32? (Score:5, Informative)
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.
Re: (Score:2)
Generally it would not hurt, but this is, after all, Slashdot so contributors assume a certain amount of "general knowledge".
Re: (Score:1)
Generally it would not hurt, but this is, after all, Slashdot so contributors assume a certain amount of "general knowledge".
The article is about how this technology is obscure, and barely used. By definition that means that even among tech people it's not particularly well known. I actually _did_ happen to know about it, but that's only because years ago I did a little research into the 2038 problem, which on Linux is connected to running a 32 bit OS. the x32 ABI came up in passing.
That was several year
Re: (Score:2)
Generally it would not hurt, but this is, after all, Slashdot so contributors assume a certain amount of "general knowledge".
An esoteric ABI so barely used that dropping its support is being considered by Linux most definitely does not qualify as general knowledge. Hell being general knowledge alone would likely be grounds for it to remain supported.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
I can't think of a system that needs no more than 4GB, but needs the extra performance of 32bit addressing space.
It would be nice to have on x86_64 embedded systems with limited memory such as these [pcengines.ch], which are commonly used for networking gear.
Re: (Score:2)
Seems x32 would reduce the memory footprint up to 25%, might be to somebody doing a tight design.
Comment removed (Score:4, Informative)
32 bits gives you 32 gig, which is still alot (Score:2)
Provided ... you do not use the C programming language.
Java has done this for a long time. Pointers only point to things that are 8 byte aligned. And you do not do pointer arithmetic just to parse a String.
Re: (Score:2)
Re: (Score:2)
386 is 'i386'. ia32 is Itanium.
Re: (Score:2)
Re: (Score:2)
Damn. You're right. I was thinking iAPX32, which was the Intel 432.
Re: (Score:2)
Why so verbose? Less is usually more:
>...began supporting the x32 ABI(which allows 64-bit code to use 32-bit pointers to reduce overhead), but already kernel developers...
Re: (Score:1)
If I'd been writing the summary, I wouldn't have necessarily included the full techno description of what x32 ABI is, which might just be techo-babble for a lot of people, but I would have added "this has nothing to do with the old 32 bit architecture intel CPUs." somewhere early on.
Re: (Score:2)
It would have required decent editors.
Re: (Score:2)
Given how many people are confused as to what x32 is, that 25% explanation in the summary clearly isn't enough.
But, hey, never pass up an opportunity to claim, "User error, as usual!", especially when talking about obscure technologies few people even know about.
Re: (Score:1)
No, not at all. The two have nothing to do with each other. x32 is not the same as x86.
Re: (Score:2)
One reason Linux has supported so many processors is that most of it has always been in written in C.
Anyone have statistics? (Score:2)
Does anyone have comments on how many apps made use of this? I know that's kind of nebulous, and a nebulous answer is fine.
Re: (Score:1)
Re: (Score:2)
No, but...
Well, in reading that, it occurred to me that it might be interesting to see if I could compile a Gentoo system in x32, but I have a few programs that really need 64-bit pointers (based on their memory footprint): X, web browsers, libreoffice, and a few others. I suppose that means I would need a multilib support for this, and that gets ugly.
Re: (Score:2)
IIRC 32-bit pointers chop something like 20% off the Firefox binary vs it's 64-bit version. That's not an inconsiderate savings.
Of course, you wouldn't want to run Firefox, Chrome, LibreOffice, or X with a 4-gig memory limit, hence the utility just isn't there for the times you would really like it.
Re: (Score:2)
To be fair, you either wouldn't want to, or you'd want to really bad. Depending.
Re: (Score:2)
Debian has an unofficial x32 port. I don't know how usable it is though.
Re: (Score:2)
The intent was to provide for a memory-efficient architecture that availed itself of the richer register space of x86_64. In practice, that's not a widespread interest (limiting to 4GB of ram support on architectures that can fundamentally support a lot more). General distributions wouldn't bother touching it (a lot of work to maintain a distro for users that have *almost* as good experience with an i686 distro), embedded applications may be more interested, but even they are outgrowing 4GB and honestly d
Re: (Score:2)
Isn't it technically less than 4GB of RAM because you still need address space for PCI devices?
Re: (Score:2)
x32 was only ever a userspace ABI; the kernel is still using x86_64 and has access to the full 64-bit address space. Only applications are limited to 4GB of virtual memory per process, just like ordinary 32-bit x86 apps under a 64-bit kernel.
Re: (Score:3)
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 additio
Re: (Score:2)
Bingo! Cache miss latency is horrible on modern CPUs. x32 reduces your data size down a bit, particularly for things like STL structures that have pointers and sizes all over the place. It's
Re: (Score:2)
Ouch - I hadn't thought of the userland and library incompatibilities.
That probably restricts its practical use to mostly embedded and research-related software with minimal/custom UIs, and OSS, which can recompile its 3rd-party libraries. Intersect that set with the software that works with less than 4GB of data, AND uses enough pointer-heavy data structures to justify the added difficulty...
Yeah, even if it were well-known, I'm just not seeing a potential user base large enough to justify the maintenance
Re: (Score:2)
Another issue is that if you know for certain that you have a 32-bit program that will always be a 32-bit program, then why wouldn't you make it a 32-bit program compatible with almost every 32-bit version of Linux out there?
When it launched, the people with 64-bit processors were purchasing them because they could reliably access more than 2 GB of RAM in user-space. Most of the operating systems and hardware architectures had configurations where the top 2 GB of RAM was reserved for operating system use.
Re: (Score:2)
Your argument is somewhat true for the majority of RISC processors, although you may be able to use full 64-bit registers if you know you're running on a 64-bit RISC CPU in 32-bit mode (it depends on whether the OS will save the full 64-bit register contents for a 32-bit process on context switch). This is useful if you're doing stuff like fixed-point maths where being able to work on twice as many bits at once is a big win, especially for multiplication and division. But for the most part, 64-bit version
Re: (Score:2)
An x32 program is NOT a 32 bit program though. It's a 64bit program using a 32-bit address space.
I think _merlin covered the high points of the distinction. Basically it seems x32 combines the performance advantages of both x86 and x64, for a specific subclass of programs that don't need more than 4GB of memory or access to proprietary 3rd party libraries.
And yes, you could possibly use 32 bit indexing instead of pointers in some situations, but that means you can't use polymorphism, have to write your ow
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
"A couple" is 2
"A few" is 3 or 4 (in some cases, 5)
"Several" is 5 6 7 8 or 9
"A bunch" is the normal amount of something plus an additional
"A lot" is the normal amount of something x2
"A shitload" is the normal amount of something x10
"A fuckload" is the normal amount of something x10 and you're drunk.
Re: (Score:2)
Re: How to use "several"? (Score:2)
Re: (Score:2)
Re: (Score:2)
As a native English speaker, those examples both make my ears bleed, so I think I agree with your point. Several doesn't just mean a specific range of numbers, but also that the speaker wants to convey that, in this context, that number is many or greater than expectation.
Re: (Score:2)
As others have answered, "several" in this context means a vague small number.
I'd like to point out that when writing up a news article, the author should have taken several minutes to look up exactly how long ago the X32 ABI was introduced.
"It was just six [kernel.org] years [kernelnewbies.org] ago..."
Re: (Score:2)
You're right that this usage is weird. The other posters are correct about what number range the word "several" might represent, but they're ignoring its connotation. You're exactly correct that it has the sense of "more than expected".
"There are still several years left", or "This established feature has been there for several years" all make sense. "It was just several years ago" does not make sense.
Missed a verb there (Score:5, Funny)
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."
Re: (Score:2)
Re: Missed a verb there (Score:3)
Worked for Reiser. Ish.
Just do it (Score:2)
Re: Just do it (Score:2)
Re: (Score:3)
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.
Re: (Score:3)
Re: (Score:2)
Hey, there, some fucking asshole here to point out that if I, or some other embedded programmer ever actually needs to use this shit we don't need OS support for it. There is absolutely no good reason to get these types of features in the OS. If I can't fit linux on the platform, I don't want to compile it smaller; I can't fit my app in either in that case. When you hit that sort of wall, you need to either spend more money on hardware, or quit trying to use a fat OS like linux.
Linux is a great server OS, b
Damnit, Linus! (Score:2)
How else will I run Linux on my SEGA Genesis?
Oh wait, x32, not 32X.
Carry on.
The correct approach (Score:2)
Is surely to provide a better abstraction layer.
I should not have to care if x32, DEC or the Prime Radiant are supported by the kernel admins. Patches should largely just work with minimal hacking.
In turn, it should not be such hard work to maintain code. Different systems have different ways to achieve the same thing with different optimizations possible.
All of that can be stuck in helper code, well almost all, which means there is far less maintenance.
This is not esoteric wisdom, its the basis behind all
Weird syscalls, but surely still workable (Score:2)
Here's the LKML post that kicked it off, if you don't want to click through: https://lkml.org/lkml/2018/12/10/1145 [lkml.org]
I think his point #2 is probably the most "nutty", but that really does seem like an implementation detail:
x32 (Score:2)
I tend to find that oddball intermediate layers like this die off rather quickly. In terms of "when I'd heard of it" to "when its death is proposed", this one is really quite quick.
I'm surprised that x86 is still supported, let alone an oddball "64-bit processor with 32-bit pointers" hybrid setup. Surely even x86 is only more for legacy and embedded chipsets, nowadays, where I can't imagine that x32 would help at all.
Either your chip is 64-bit capable, or not. If it is, even if there are minor advantages
Nooo! (Score:3)
So many naysayers. (Score:1)
I'm an embedded dev, and this is totally useful on any platform with 4G of memory, which is a lot of them. It is, in fact, probably the most optimal way to run an x86_64 processors on a platform that actually does not need more than 32 bits of address space. This is a non-trivial number of applications. Like, lots. There are computers beyond servers and engineering workstations ya know. Lots more. You just conveniently pretend embedded and/or purpose-built systems are designed and programmed by magic
No No No!! I am still hoping for 8-bit support.. (Score:2)
I am still hoping for 8-bit support one day for the M6809 processor... Dang.
Honestly -- I don't know why there ever was so much movement toward x64 -- everything takes more memory..