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.

90 of 202 comments (clear)

  1. What is x32? by Megane · · Score: 4, 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.

    --
    #naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
    1. Re:What is x32? by dunkelfalke · · Score: 1

      Generally it would not hurt, but this is, after all, Slashdot so contributors assume a certain amount of "general knowledge".

      --
      "It's such a fine line between stupid and clever" -- David St. Hubbins, Spinal Tap
    2. Re:What is x32? by squiggleslash · · Score: 1

      I guarantee that 90% of the responses to this article will think they're dropping ia32/x86 support (or whatever you call the architecture that began on the 80386)...

      To give an on-topic response, I think it's a shame, but predictable. Most people are either interested in full 64 bit or in backward compatibility, the benefits of X32 were obvious but marginal, a slight performance improvement in return for the need to recompile everything and be limited to 32 bit addressing in the future at a time when 4G no longer seems like a huge amount of memory.

      --
      You are not alone. This is not normal. None of this is normal.
    3. Re:What is x32? by Anonymous Coward · · 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 years ago. This is the first time I've heard anyone mention it since.

    4. Re:What is x32? by xvan · · Score: 1

      I can't think of a system that needs no more than 4GB, but needs the extra performance of 32bit addressing space.

    5. Re:What is x32? by thegarbz · · Score: 1

      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.

    6. Re:What is x32? by pak9rabid · · Score: 1

      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, which are commonly used for networking gear.

    7. Re:What is x32? by sconeu · · Score: 1

      386 is 'i386'. ia32 is Itanium.

      --
      General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
    8. Re:What is x32? by Immerman · · Score: 1

      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...

      --
      --- Most topics have many sides worth arguing, allow me to take one opposite you.
    9. Re:What is x32? by shoor · · 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.

      --
      In theory, theory and practice are the same; in practice they're different. (Yogi Berra & A. Einstein)
    10. Re:What is x32? by squiggleslash · · Score: 1

      ia64 is Itanium. ia32 is the architecture introduced in the 80386.

      Yeah, I know, it got confusing when the AMD 64 bit thing happened.

      --
      You are not alone. This is not normal. None of this is normal.
    11. Re:What is x32? by xvan · · Score: 1

      I thought of those at first, but in such case, the issue is memory space and not memory access time which would be improved. Found these benchmarks(end of post)

      Seems x32 would reduce the memory footprint up to 25%, might be to somebody doing a tight design.

    12. Re:What is x32? by squiggleslash · · Score: 3, Informative

      The extra performance you get out of X32 is the use of AMD's more optimal 64 bit instruction set. It's not about the address space, it's about the fact you have faster instructions, you have more registers, and you can process 64 bit values (integers, bit masks, etc) in almost the same amount of time it takes to process a 32 bit value. Remember that the 80386 was never considered an optimal CPU, it was the best Intel could do at the time with the conflicting needs of not having Motorola eat their lunch, while ensuring old software written for their previous, shittier, architectures, could easily run on the new system.

      The logic behind X32 was that most applications (which was true at the time) have no need for 64 bit addresses (or, to be more accurate, 33 bit addresses), but would benefit from the AMD ABI's faster instructions. And to be fair, that's still true, it's just we all know it's not going to be true for much longer Firefox.

      --
      You are not alone. This is not normal. None of this is normal.
    13. Re:What is x32? by sconeu · · Score: 1

      Damn. You're right. I was thinking iAPX32, which was the Intel 432.

      --
      General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
    14. Re:What is x32? by SigmundFloyd · · Score: 1

      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.

      It would have required decent editors.

      --
      Knowledge is power; knowledge shared is power lost.
    15. Re:What is x32? by Waccoon · · Score: 1

      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.

    16. Re:What is x32? by squiggleslash · · Score: 1

      You're thinking of something else. X32 is merely the amd64 (ix86-64) instruction set used with 32 bit pointers. It has nothing to do with Atom or SSE3. X32 was proposed by Donald Knuth (yep, THAT Donald Knuth) shortly after AMD64 came into existence.

      --
      You are not alone. This is not normal. None of this is normal.
  2. Re: No! by Anonymous Coward · · Score: 4, Insightful

    That's not what the x32 ABI is for.

  3. Re:No! by Misagon · · 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 ;)

    --
    "We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
  4. Re:No! by mridoni · · Score: 3, 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.

  5. x32 does not mean what you think it means by Anonymous Coward · · Score: 1

    Wikipedia:

    The x32 ABI is an application binary interface (ABI) and one of the interfaces of the Linux kernel. It allows programs to take advantage of the benefits of x86-64 instruction set (larger number of CPU registers, better floating-point performance, faster position-independent code, shared libraries, function parameters passed via registers, faster syscall instruction) while using 32-bit pointers and thus avoiding the overhead of 64-bit pointers.

    It's a 64-bit CPU thing, not a 32-bit CPU thing.

  6. Re:No! by Anonymous Coward · · 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

  7. Re:No! by Anonymous Coward · · 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.

  8. Anyone have statistics? by Maury+Markowitz · · Score: 1

    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.

    1. Re:Anyone have statistics? by crow · · Score: 1

      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.

    2. Re:Anyone have statistics? by Junta · · Score: 1

      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 don't generally need that extra oomph of x32 v. x86 (at least the areas that would even think of using an x86_64 platform in the first place, not a popular embedded choice).

      --
      XML is like violence. If it doesn't solve the problem, use more.
    3. Re:Anyone have statistics? by Immerman · · Score: 2

      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.
    4. Re:Anyone have statistics? by quintus_horatius · · Score: 1

      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.

    5. Re:Anyone have statistics? by LordNimon · · Score: 1

      Isn't it technically less than 4GB of RAM because you still need address space for PCI devices?

      --
      And the men who hold high places must be the ones who start
      To mold a new reality... closer to the heart
    6. Re:Anyone have statistics? by petermgreen · · Score: 1

      Debian has an unofficial x32 port. I don't know how usable it is though.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    7. Re:Anyone have statistics? by JesseMcDonald · · Score: 1

      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.

      --
      "The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
    8. Re:Anyone have statistics? by Aighearach · · Score: 1

      To be fair, you either wouldn't want to, or you'd want to really bad. Depending.

    9. Re:Anyone have statistics? by _merlin · · Score: 1

      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.

      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 a nice idea in theory, but the trouble is you have to build your own userland, and forget third-party libraries.

    10. Re:Anyone have statistics? by Immerman · · Score: 1

      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 overhead.

      --
      --- Most topics have many sides worth arguing, allow me to take one opposite you.
    11. Re:Anyone have statistics? by Cassini2 · · Score: 1

      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. Sometime versions of operating systems permitted 3GB of user-space RAM. It was almost impossible to utilize a full 4GB of RAM on a 32-bit processor.

      This created a hunger. If you have a program that might need more than 2 GB of RAM some point in the future, then 64-bit is the way to go.

      Not much has changed since the 64-bit processors launched. If you have programs that will only require 32-bits, then the standard proven x86 and ARM architectures are the way to go. This applies in embedded systems too. In embedded, you want a well-proven tool chain.

      If you have an intensively used data structure that is less than 2 GB in size, then it can often be represented as an 32-bit index into an array. This compiles cleanly with both 32-bit and 64-bit compilers. With the hardware support on modern processors, it has about the same execution speed as using 32-bit pointers.

      This leaves the x32 ABI supporting non-price sensitive programs that need the speed of a 64-bit processor, do not have data structures that can be represented as an arrays, will not need 64-bits, and run on specific hardware/software stacks. It is a niche market at best. I imagine someone has used it for something, but it is hard to envision an application specifically requires the x32 ABI. For a 32-bit application, the 386 instruction set is good enough.

    12. Re:Anyone have statistics? by _merlin · · Score: 1

      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 versions of RISC CPUs largely work like their 32-bit predecessors, just with bigger registers (yes, AArch64 is an exception, being very much not ARM).

      There are factors peculiar to x86 that make x32 a much bigger win than you might think. The 32-bit x86 instruction set has very few architectural registers, doesn't support PC-relative addressing, and is not orthogonal. Firstly, this means that for any computationally-heavy code you spend a lot of instructions spilling and reloading registers. Even with rename registers, this consumes decode/issue/retire bandwidth and increases the image size, which consumes memory bandwidth. Lack of PC-relative addressing makes position-independent code a lot less efficient than it would be otherwise (think shared libraries and ASLR). This means that computationally expensive code typically gains 20% to 30% performance just by targeting x86-64 rather than i686, even if it would never need a large addressable space.

    13. Re:Anyone have statistics? by Immerman · · Score: 1

      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 own memory handlers if anything will ever be "delete"d, probably need to pre-allocate all the data space you might possibly need (or used a paged array, but that comes with additional performance overhead), and need to leave all of your data accessible to all aspects of your program. Not an ideal solution.

      --
      --- Most topics have many sides worth arguing, allow me to take one opposite you.
  9. Comment removed by account_deleted · · Score: 2, Insightful

    Comment removed based on user account deletion

  10. Re:No! by Desler · · Score: 1

    A 486 does not support x32.

  11. Re:What about original code? by Desler · · Score: 1

    No, not at all. The two have nothing to do with each other. x32 is not the same as x86.

  12. Re: No! by Desler · · 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.

  13. Re:How to use "several"? by pahles · · Score: 1
    --
    Sig?
  14. Re: No! by lgw · · Score: 3, 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.

    --
    Socialism: a lie told by totalitarians and believed by fools.
  15. Re:How to use "several"? by jfdavis668 · · Score: 1

    Several refers to a small count of some group of items. "Few" is a similar word. "Several years" could refer to anything from 2-10 years in conversation. It does not imply less or more than something else. You could say "it took several years more than expected" if you are referring to something taking a longer time. But, it is still referring to a small quantity of years. You could also say it took several years less than expected" if it happened faster than the estimated amount of time.

  16. Re:What about original code? by doconnor · · Score: 1

    One reason Linux has supported so many processors is that most of it has always been in written in C.

  17. Missed a verb there by GreyWanderingRogue · · Score: 5, Funny

    Linus Torvalds is in favor of sunsetting x32 and many other upstream contributors in favor of seeing it deprecated and removed

    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."

    1. Re:Missed a verb there by Zocalo · · Score: 1

      On the plus side, "sunsetting" is clearly a lot of progress compared to some of Linus' previous LKML putdowns so clearly that timeout has had the intended effect in getting "some assistance on how to understand people's emotions and respond appropriately." "Sunsetting" almost sounds like it would be pleasant experience, maybe with cocktails or something...

      --
      UNIX? They're not even circumcised! Savages!
    2. Re: Missed a verb there by jd · · Score: 2

      Worked for Reiser. Ish.

      --
      It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
  18. Just do it by Artem+S.+Tashkinov · · Score: 1

    How many people use it? 50? 500? I see no reason for it to exist. It's not like Open Source has too much manpower to afford supporting a queer architecture barely used by anyone.

    1. Re: Just do it by UnknowingFool · · Score: 1

      Yeah I'm not sure of what the justification was to create it. The only scenario I can see is that for a short while some systems like ARM had to use it while transitioning to full 64-bit and needed a stopgap where the hardware could handle 64-bit but not all the systems were ready for it.

      --
      Well, there's spam egg sausage and spam, that's not got much spam in it.
    2. Re:Just do it by Artem+S.+Tashkinov · · Score: 2

      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.

    3. Re:Just do it by Artem+S.+Tashkinov · · Score: 2

      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.

    4. Re:Just do it by Aighearach · · Score: 1

      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, but it actually sucks as an embedded OS; it is optimized for throughput, which gives benefits when you have a fatter system. The only reason that it is used a lot on "embedded" systems is because those a are larger systems that simply have a different UI than a desktop. It is great for that. But it sucks when you're resource-constrained.

  19. Re:How to use "several"? by BringsApples · · Score: 1

    "One" is 1
    "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 .25% - .50%
    "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.

    --
    Politics; n. : A religion whereby man is god.
  20. Re:How to use "several"? by BringsApples · · Score: 1

    Woops, "A bunch" is the normal amount of something plus an additional 25% - 50%

    --
    Politics; n. : A religion whereby man is god.
  21. Re: No! by willaien · · Score: 1

    Not to mention that x32 still lets you use 64-bit native words, etc. for faster computation with the smaller memory footprint.

  22. Re: How to use "several"? by UnknowingFool · · Score: 1

    Can you relate that in the standard slashdot unit of measure, the Library of Congress (LOC)? :)

    --
    Well, there's spam egg sausage and spam, that's not got much spam in it.
  23. Damnit, Linus! by DontBeAMoran · · Score: 1

    How else will I run Linux on my SEGA Genesis?

    Oh wait, x32, not 32X.

    Carry on.

    --
    #DeleteFacebook
  24. Re: No! by _merlin · · Score: 1

    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.

  25. The correct approach by jd · · Score: 1

    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 abstraction layers and the arch directory.

    If there's a problem, it's because the job is half done.

    Remove support only if nobody is stuck without it and it's trivial for users to add if they do need it.

    --
    It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
  26. Re:How to use "several"? by bigdavex · · Score: 1

    "It was just several years ago" or "Only several days left".

    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.

    --
    -Dave
  27. Re:No! by aitikin · · Score: 1

    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...

    --
    "Don't meddle in the affairs of a patent dragon, for thou art tasty and good with ketchup." ~ohcrapitssteve
  28. Re: No! by Anonymous Coward · · 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.

  29. Re:How to use "several"? by jdschulteis · · Score: 1

    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 years ago..."

  30. Re:No! by thegarbz · · Score: 4, 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.

  31. Re:How to use "several"? by aitikin · · Score: 1
    --
    "Don't meddle in the affairs of a patent dragon, for thou art tasty and good with ketchup." ~ohcrapitssteve
  32. Weird syscalls, but surely still workable by Etcetera · · Score: 1

    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

    I think his point #2 is probably the most "nutty", but that really does seem like an implementation detail:

    2. The way that system calls work is very strange. Most syscalls on
    x32 enter through their *native* (i.e. not COMPAT_SYSCALL_DEFINE)
    entry point, and this is intentional. For example, adjtimex() uses
    the native entry, not the compat entry, because x32's struct timex
    matches the x86_64 layout. But a handful of syscalls have separate
    entry points -- these are the syscalls starting at 512. These enter
    through the COMPAT_SYSCALL_DEFINE entry points.

    The x32 syscalls that are *not* in the 512 range violate all semblance
    of kernel syscall convention. In the syscall handlers,
    in_compat_syscall() returns true, but the COMPAT_SYSCALL_DEFINE entry
    is not invoked. This is nutty and risks breaking things when people
    refactor their syscall implementations. And no one tests these
    things. Similarly, if someone calls any of the syscalls below 512 but
    sets bit 31 in RAX, then the native entry will be called with
    in_compat_set().

    x32 support removal is the kind of thing that should be thought long and hard about, because it's the kind of thing that will be nearly impossible to put back in once it's removed. Abstraction layers and edge cases keep us (and the kernel devs) honest, and have some value even if the number of users is small. Additionally, this seems like a classic case of chicken-and-egg with a lesser-used arch variation. Perhaps actual *publicity* after it was put in 6 years ago would have helped; perhaps this story itself will prompt more use.

  33. Re: No! by lgw · · Score: 1

    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.

    --
    Socialism: a lie told by totalitarians and believed by fools.
  34. Re: No! by Chris+Mattern · · Score: 1

    Never understood who thought this was a good idea.

    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?

  35. musl libc has supported it for years. by Anonymous Coward · · 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. Furthermore if they are fucking around with the syscall interface often enough for it to affect ABI compatibility, maybe they should be taking a hard look at their own development practices instead of those of other developers.

  36. Re:No! by Frederic54 · · Score: 2

    Ah damn ok it isn't x86, I was confused...

    --
    "Science will win because it works." - Stephen Hawking
  37. Re:How to use "several"? by XanC · · Score: 1

    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.

  38. Re:Correct lgw (used it in function/proc calls) by lgw · · Score: 1

    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.

    --
    Socialism: a lie told by totalitarians and believed by fools.
  39. x32 by ledow · · Score: 1

    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 to running it in 32-bit mode, when there is COMPLETE and total support for 64-bit mode, it seems a nonsense not to use it. If it's not, then the question is moot anyway.

    It's not like ARM or Intel of old where all the previous chips used 32-bit, then they supported 64-bit but people didn't get on board with it for a while. It's people with full-64-bit support, that can run either full 64-bit or full 32-bit, but choose to use an oddball and barely-supported middle ground because... well.. they don't want to use 64-bit pointers and use a little more memory.

    It's like running your 80386 in 8086 mode. It may have been useful for a short period of time in the transition when the new hardware was expensive but the old software was more expensive to replace, but it'll die off and you'll never use it again. Except, in this case, it's wanting to use the 80386 chip features in a machine, but in such a way that it can only address 1Mb of RAM. Not even "use the 80386 as an 8086" but literally "I want to use the extra processor registers but not the full 4Gb of RAM, just the first Mb".

    And in an era where 64-bit hardware has been the norm for nearly 2 decades now.

  40. Nooo! by ReneR · · Score: 2

    Don't take the 10% advance away from me! :-/ https://t2sde.org/

  41. Re: It's VERY clear Al Gore = hypocrite conman by Anonymous Coward · · 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 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.

  42. Re: LMAO - Look @ your "ReAcTioN", lol... apk by Anonymous Coward · · 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 your spam. You are simply incorrect when you say this is the work of a single "mental loon" because many more users would have to agree your posts are of low quality.

    Why are you so obsessed with how your posts are moderated? That would not seem to be healthy. You've turned to posting cconspiracy theories that this is one user out to get you. You've recently started posting again about your obsession with whipslash and how you're still upset after two years that he modified the lameness filter to limit some of your spam.

    Seek professional help.

  43. Re: Al Gore & conmen like him = hypocrites by lgw · · Score: 1, 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 an actual science where original work is happening. If it were all so clear, it wouldn't be a field of study.

    Just to start: almost all of the greenhouse* effect comes from water vapor. The atmosphere is effectively saturated, so the key is how much water can the air hold at a given temperature. Warmer air holds more water, so positive feedback. But wait, more clouds increases the Earth's albedo, so negative feedback. This also is why no climate (or weather) model is meaningful without modeling the oceans (ocean temps matter a heck of a lot).

    *"Greenhouse" effect is a stupid name. Greenhouses work by letting in light and blocking convective losses (and limiting conductive too, in anything modern). Glass trapping outgoing IR barely matters.

    --
    Socialism: a lie told by totalitarians and believed by fools.
  44. Re:No! by Anonymous Coward · · 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.

  45. Re: No! by sa666_666 · · Score: 1

    Never understood who thought this was a good idea.

    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.

  46. Re: No! by Chris+Mattern · · Score: 1

    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.

    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.

  47. Re: No! by Aighearach · · Score: 1

    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.

  48. Re: No! by Aighearach · · Score: 3, 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.

  49. So many naysayers. by Anonymous Coward · · 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.

  50. Re: No! by Aighearach · · Score: 1

    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.

  51. Re: No! by Aighearach · · Score: 1

    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.

  52. No No No!! I am still hoping for 8-bit support.. by Slicker · · Score: 1

    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..

  53. 32 bits gives you 32 gig, which is still alot by aberglas · · Score: 1

    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.

  54. Re: Al Gore & conmen like him = hypocrites by lgw · · Score: 1

    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 climate be heading without human activity. Solar models are even more primitive than climate models, so no one has a clue, but it's the most important question. Glaciers are a far worse threat than warming, at least to us humans, but they're already 10k years overdue, and just maybe the Quaternary Ice Age is ending, and it's going to get a lot warmer.

    --
    Socialism: a lie told by totalitarians and believed by fools.
  55. Re:No! by proto · · Score: 1

    Its nice to see an informative post by a dedicated Slashdot fan (a rare action now a days). I ran out of mod points but I thing I would friend you instead. Thanks Misagon.