Hacker News Reader

Comment by jsheard | Hacker News Reader

> Does any of this matter still or should we embrace this 64 bit only world? Will CPU makers remove i686 support? I guess we're going to find out.

We're already on this path, Intel has proposed an "X86-S" subset which drops support for booting into 16/32-bit modes (though 32-bit applications would still be supported under a 64-bit OS), ARM Cortex-A cores already dropped support for 32-bit boot a few years ago and the latest ones are also dropping support for 32-bit applications, so the whole stack has to be 64-bit. Apple preemptively killed 32-bit apps even on hardware that could technically still support them, and their current hardware doesn't support 32-bit at all, not even in Rosetta.

View on HN

For the modern server/desktop and even laptop, that's also no bad thing. It is somewhat ridiculous that UEFI bioses, internally, still boot in 16-bit real mode and have to do all the steps your bios bootloader used to do to set up a 64-bit environment ready to go: https://github.com/tianocore/edk2/blob/edc6681206c1a8791981a..., https://github.com/tianocore/edk2/blob/edc6681206c1a8791981a..., https://github.com/tianocore/edk2/blob/edc6681206c1a8791981a...

Why not just start the CPU in "long mode", which is what everyone is using it for, in the first place?

These newer ARM processors support 32-bit code at EL0 only (userspace). That seems like a reasonable approach for x86 as well and the freebsd announcement has this to say:

> There is currently no plan to remove support for 32-bit binaries on 64-bit kernels.

So for the moment, you can run 32-bit applications just fine.

> These newer ARM processors support 32-bit code at EL0 only (userspace).

Even that is being phased out, starting from 2021 ARMs reference cores mostly dropped 32-bit support, with the Cortex-X2 big cores and Cortex-A510 small cores being 64-bit only, and only the medium Cortex-A710 cores retaining the ability to run 32-bit code in userspace. With the next generation the medium cores lost 32-bit support, but the small cores gained 32-bit support again, so the chips can barely still run 32-bit code but it's relegated to only running on the least performant cores. I'm sure they'll drop it altogether as soon as they think the market will accept it.

I think we need to be more specific, since on x86 64bit instructions are a superset of 32bit. On ARM they are different with AArch32 and AArch64 being two separate set of instructions. It is AArch32 that is being dropped and no longer required.

They’re mostly a superset, but also some instructions were dropped like the bcd opcodes.

https://en.m.wikipedia.org/wiki/Intel_BCD_opcodes

> Why not just start the CPU in "long mode", which is what everyone is using it for, in the first place?

Why not indeed?

https://www.intel.com/content/www/us/en/developer/articles/t...

Not even a new idea!

https://en.wikipedia.org/wiki/Intel_80376

> It differed from the 80386 in not supporting real mode (the processor booted directly into 32-bit protected mode)

... although it didn't support paging.

> Why not just start the CPU in "long mode", which is what everyone is using it for, in the first place?

Are you sure it's "everyone"? No doubt it's "overwhelming majority", but that's not the same, and "everyone" is a lot of people.

As I understand how this works, the compatibility is perhaps slightly inconvenient to a small group of developers, but not that inconvenient and generally relatively cheap. So why not have and keep it?

ARM has a lot less history than x86. Yes, it goes back to 1985 in the BBC Micro, but didn't really see serious usage as a "generic platform" until the late 90s/early 2000s.

Do you ever boot your machine only into 32-bit mode? Most UEFI firmware I've seen is launching /EFI/BOOT/BOOTX64.EFI, which means your bootloader is in long mode even if you then switch back to 32-bit mode (and UEFI is likely already there). I don't know if emulating a traditional bios avoids this or not, never thought about it. But I'd take a guess that the vast majority of people are passing through long mode and then back again if they installed a 32-bit OS.

I'm not saying remove the possibility of 32-bit userspace and nor are, it seems, freebsd. I am saying don't bother with a 32-bit kernel. Otherwise you're limited to a 4GB address space and hacks like PAE. No harm in running 32-bit binaries if you want and, I think Solaris actually left userspace as 32-bit only even on their 64-bit OS, unless the application really benefited from a 64-bit setup. Not sure what they do now, been a while since I used it.

It's arguable ASLR only works well in a 64-bit mode, as well.

> Do you ever boot your machine only into 32-bit mode?

No, but I'm not everyone.

Or let me put it this way: I don't know the motivation for why the things work like they do. It's entirely possible there is no good reason at all. Or maybe there is? Either way, I wouldn't assume anything so quickly.

Intel is currently trying to find out if it's everyone. The whole point of announcing the idea of dropping the old modes years before you plan to actually do so is to give a chance for people to speak up if it's a problem.

Rosetta supports 32-bit code execution via a very basic (segment-level) facility, designed for use by Wine.

TIL. I'm surprised they went out of their way to accomodate emulating 32-bit Windows apps, when they cut off 32-bit Mac apps completely.

Dropping 32-bit macOS apps let them drop the second copy of every system library, and possibly even more importantly, support for the old obj-c runtime that was weird and different from the runtime used on every other platform. Supporting 32-bit wine is a much smaller burden.

Which is especially useful on phones that are much more memory constrained than desktops.

> Apple preemptively killed 32-bit apps even on hardware that could technically still support them, and their current hardware doesn't support 32-bit at all, not even in Rosetta.

Slightly related: visionOS references "iOS" for old 32-bit apps when you view them on the App Store. https://rr.judge.sh/Acaciarat%2FIMG_0002.PNG

Reply on news.ycombinator.com