> If you want to keep building software on by now ancient hardware, they’ll still give you the tools to do it
There are other use-cases, though not exactly popular or mainstream, but supposing you need dozens, hundreds, maybe even over a thousand currently-supported Windows VMs running off a single VM host box: you'll achieve a higher VM density with an x86 build of an OS compared to the x64 build; right now the only option is some cut-down custom build of Windows 10 Embedded x86[1]
...though I'm sure no-one outside of a DEFCON or CCC meetup's drinking-game will ever find themselves doing this - just so long as I get to see it in a youtube video.
[1] EDIT: Turns out they renamed the (non-CE) NT-based Windows Embedded to "Windows IoT" - which annoys me because it's perfectly allowed to make a Windows IoT build without any networking features enabled - so it'd be like calling Apple's iPod Touch as Apple's "iPod iPhone".
----
I'll admit I'm surprised that "x32" (i.e. AMD64 ISA, but with 32-bit pointers) was never supported on Windows, nor exactly popular on Linux, because (at least before Electon Apps existed) plenty of software really has no business using 64-bit pointers, so it makes sense to keep 32-bit pointers; another benefit-of-sorts is that if your program has a memory-leak then it'll crash once the leak hits 4GB - but with 64-bit pointers your process might end-up gobbling hundreds of gigs of RAM before the next malloc call fails.
While we're at it, let's also bring back Intel's 21-bit NEAR/FAR pointers ("segmented memory") if only to keep Rust programmers (and their compiler team) on their toes.
So, the Rust team didn’t say they wouldn’t support it, but more that they couldn’t. They’re don’t have in-house experts today who are experienced enough with that platform to support it efficiently. I’d say that a person or company who needs to run thousands of VMs on a single machine would be exactly the right one to step up and adopt it as a maintainer.
True, but, the advantage of using 32 bit pointers to save a couple of RAM is not that important, since applications typically don't use that much pointers, thus if you half the size of them you will save probably a couple of kb of RAM.
Maintaining the support for a different architecture only for that doesn't make a lot of sense, probably the reason it was never supported. RAM is cheap these days so...
Pointers are everywhere. In real world applications we see an increase between a quarter to a third. For example in 2016 Mozilla reported 25% increase from 32-bit Firefox to 64-bit [1]. Google deemed it necessary to implement pointer compression in Chrome to counter the effect. Java also has pointer compression.
It’s not just a problem for size, don’t forget you also have to copy bits across busses and several layers of cache - and doing so is not instant!
And that’s just thinking in terms of logical RAM. You then have translation tables which pointers need to index into - having them larger makes indexing even more slower, compounding the issue
It can be important, but also there are ways of using compressed pointers on 64-bit systems for similar savings. Search/prompt "What modern systems or programming/runtime environments use compressed pointers of some form?" for details.
There are other use-cases, though not exactly popular or mainstream, but supposing you need dozens, hundreds, maybe even over a thousand currently-supported Windows VMs running off a single VM host box: you'll achieve a higher VM density with an x86 build of an OS compared to the x64 build; right now the only option is some cut-down custom build of Windows 10 Embedded x86[1]
...though I'm sure no-one outside of a DEFCON or CCC meetup's drinking-game will ever find themselves doing this - just so long as I get to see it in a youtube video.
[1] EDIT: Turns out they renamed the (non-CE) NT-based Windows Embedded to "Windows IoT" - which annoys me because it's perfectly allowed to make a Windows IoT build without any networking features enabled - so it'd be like calling Apple's iPod Touch as Apple's "iPod iPhone".
----
I'll admit I'm surprised that "x32" (i.e. AMD64 ISA, but with 32-bit pointers) was never supported on Windows, nor exactly popular on Linux, because (at least before Electon Apps existed) plenty of software really has no business using 64-bit pointers, so it makes sense to keep 32-bit pointers; another benefit-of-sorts is that if your program has a memory-leak then it'll crash once the leak hits 4GB - but with 64-bit pointers your process might end-up gobbling hundreds of gigs of RAM before the next malloc call fails.
While we're at it, let's also bring back Intel's 21-bit NEAR/FAR pointers ("segmented memory") if only to keep Rust programmers (and their compiler team) on their toes.