8 ms·
Intel mulls cutting 16 and 32-bit support, booting straight into 64-bit mode
- CrLf 3y ago"Since its introduction over 20 years ago, the Intel® 64 architecture became the dominant operating mode." This is how Intel takes credit for AMD's x86-64.
- deaddodo 3y agoI still shake my head at how they were able to successfully rebrand it from amd64 to x86-64; yet ia32 is still semi-accepted as the "official" name of x86.
- ed25519FUUU 3y agoI’m not sure they’ve been successful. The string amd64 is everywhere.
- ghshephard 3y agoWithout going through various repos, I'm struggling to recall ever even seeing "x86-64" - It's always amd64 that I look for - so the rebrand wasn't that successful.
- milsorgen 3y agoI remember it a fair bit right after 64 bit became mainstream. In the excitement phase it was generally amd64 then as it became fully established and adopted it was most often referred to as x86-64, at least in the press.
- zamadatix 3y agoI think both are pretty common. E.g. uname -a says x86_64 and GCC/Clang use x86-64 for defining the target while, on the other hand, MSVC (and a lot of Microsoft stuff in general) uses amd64 as do many BSDs.
- 908B64B197 3y ago> MSVC (and a lot of Microsoft stuff in general) uses amd64 as do many BSDs. That's partly because Microsoft had support for ia32 (x86) and ia64 (Itanium). So amd64 was to differentiate the architecture (and it was unclear Intel would ever extend x86).
- viraptor 3y agoDebian-based systems are slightly confused with dpkg architecture returning amd64 and uname returning x86_64.
- usefulcat 3y agoCompiler explorer (godbolt.org) uses x86-64, as do the man pages for gcc and clang. I suspect there are plenty of other places too.
- m463 3y agoBut my filesystem is full of references like /usr/lib/x86_64-linux-gnu
- bombcar 3y agoIt makes it clearly different from arm64 at least, which may be part of it.
- JoshTriplett 3y agoamd64 was an attempt to "brand" the 64-bit version of x86, just as ia32 was an attempt to "brand" the 32-bit version of x86. Many people rejected both and just say x86 and x86-64 as generic names.
- roqi 3y ago> amd64 was an attempt to "brand" the 64-bit version of x86 The "64-bit version of x86" is actually the new ISA created by AMD that was backwards compatible with x86 and added a 64-bit mode. I'm sure that you agree that the company that creates a ISA has the right to name it.
- JoshTriplett 3y agoThey have every right to say what they'd rather it be called, and others have every right to ignore them and use a generic name if they prefer.
- CodeArtisan 3y agoAMD64 is specific to AMD, then Intel released EM64T. x86-64 is the common subset between the two.
- fomine3 3y agoIt was IA-32e, terrible name
- brundolf 3y agoEarlier today I used `arch -x86_64` on my mac to run something in Rosetta (Intel mode)
- filmor 3y agox86-64 was the original name by AMD, they rebranded it shortly before commercial availability to AMD64. Kernels and compilers had already been updated at that time and just kept the "old" name.
- cesarb 3y ago> I still shake my head at how they were able to successfully rebrand it from amd64 to x86-64 It's the opposite: the original name was x86-64, and amd64 is a later rebranding. See, for instance, the original web site for this (then) new architecture: https://web.archive.org/web/20000829042251/http://www.x86-64.org/about https://web.archive.org/web/20000829042251/http://www.x86-64...
- shiomiru 3y agoI get the opposite impression: amd64 is something I see quite often, while ia32 is pretty much exclusively referred to as x86. (Even though for the average user, ia32 would be much easier to recognize as "32-bit", and amd64 as "64-bit", both of which are often found on download buttons.)
- askvictor 3y agoamd64 looks much too similar to arm64 (though that's the latter's fault)
- alfalfasprout 3y agothere'a also `aarch64`
- pgeorgi 3y agoarm64's official name is AArch64
- naikrovek 3y agoI don't think that's the case anymore. at the very least they are interchangeable names, and I believe that "arm64" is the name going forward. I read this somewhere a couple weeks back, but I don't remember the source.
- pgeorgi 3y agohttps://developer.arm.com/architectures https://developer.arm.com/architectures mentions AArch64, no mention of arm64. There's "A64" for the instruction set, and https://developer.arm.com/Architectures/A64%20Instruction%20Set%20Architecture https://developer.arm.com/Architectures/A64%20Instruction%20... also mentions the various armv8-* names, but still no mention of arm64.
- sidewndr46 3y agoMy understanding is that the cross licensing agreement with AMD allows them to license the technology and brand it as their own.
- quantified 3y agoThank Microsoft for holding up 64-bit Windows until Intel had a chip.
- macjohnmcc 3y agoThey were doing Windows NT for the Itanium. They were holding out hoping that this thing would take off.
- rbanffy 3y agoI remember they didn’t port a lot of stuff to it - it was running mostly the BackOffice family of server apps. I don’t think one could run Outlook on them.
- macjohnmcc 3y agoWhen I was at Microsoft during the time I had X86, Alpha, MIPS, PPC (for a short time) and Itanium. We only did the builds for Itanium once in a while because the developers and the testers shared the expensive hardware. I believe the only versions of the product (Systems Management Server) were for the X86, Alpha and MIPS.
- DaiPlusPlus 3y agoWindows XP x64 Edition was released for AMD64 around 2003-2004 before Intel’s x64 chips were out, the only CPUs were Athlon64.
- lancebeet 3y agoI recall using XP x64 edition on an Athlon64. I remember it having such poor software support that it was barely usable. I heard it was actually a version of Windows Server that they put the XP GUI on top of, but I'm not sure if that's true (Wikipedia only seems to partially corroborate it).
- bombcar 3y ago
- danudey 3y agoIt still blows my mind that a 64-bit i9-13900K with 24 cores, 36 MB of cache, and a turbo speed of 5.8 GHz has to pretend to be a 16-bit 8086, which had a clock speed of 5-10 MHz and was discontinued in 1998, just to properly boot itself. (An exaggerated oversimplification I know, but still)
- ithkuil 3y agoIt's even worse than that. If it was just the CPU... It also simulate an old keyboard controller for the purpose of enabling the A20 gate which enables an address line. https://en.m.wikipedia.org/wiki/A20_line https://en.m.wikipedia.org/wiki/A20_line
- armada651 3y agoSupport for the A20 gate was actually already dropped as per the article you linked: > Intel no longer supports the A20 gate, starting with Haswell.
- jylam 3y agoIt was not needed anymore in Haswell, but the support was still there. It isn't supported at all anymore.
- deaddodo 3y agoThe A20 gate was deprecated (and made software-based) in Nehalem, then was removed completely in Haswell. It's never been a feature of the Zen µarch(s).
- bonzini 3y agoEmulation of the keyboard controller is done by the firmware. The processor's support for A20 was tied to port 92h.
- Dwedit 3y agoThe A20 line was famously used to hack the original XBox. By clearing A20, you prevent the XBox from booting from the hidden ROM, and it boots from regular flash ROM instead. Some great videos about that on YouTube if you want to look.
- CalChris 3y agoIntel should gut as much cruft as possible, 16+32 bit support is cruft for anything with 64 bit, and also double the general purpose register set with another REX prefix trick. Indeed, AMD should have done this back in 1999.
- mschuster91 3y ago> Intel should gut as much cruft as possible Gutting 32-bit support will kill off a lot of legacy applications. Apple could only do it because there aren't that many enterprise applications and they provided reasonably well working tooling to ease the effort.
- arcticbull 3y ago> Gutting 32-bit support will kill off a lot of legacy applications. Nah, they can be emulated. Just as Apple continues to support x86 apps on ARM, and supported PowerPC apps on Intel, and m68k apps on PowerPC.
- danudey 3y agoThere is a huge amount of Windows software that's still 32-bit (or at least, installs into `Program Files (x86)`), so unless Microsoft is going to start handling that kind of emulation natively in their OS (which they may decide to do), it's going to break a huge amount of stuff. Removing 16-bit and 32-bit OS support, on the other hand, makes perfect sense.
- arcticbull 3y agoYes, it would have to be done at the OS level. I don't see that as a blocker.
- microtonal 3y agoIt works both ways. Axing 32-bit support is going to make it impossible to use a large collection of software. On the other hand, supporting legacy architectures, legacy APIs, etc. for decades also makes developers and users lazy. There needs to be some balance.
- MrBuddyCasino 3y agopreviously: https://news.ycombinator.com/item?id=36006446 https://news.ycombinator.com/item?id=36006446
- lproven 3y agoHi. Article author here. Yes, that is the original, but I tried to add a lot of historical context and precedent. Whether that is interesting or worthwhile I leave to the readers, but my story seems to be doing well and getting lots of comments and shares, so I guess I succeeded.
- snvzz 3y agoA reference to the current context (e.g. RISC-V exists) wouldn't have hurt.
- donatj 3y ago> only two mainstream PC OSes ever actually used more than these two rings. One was IBM's OS/2 I'm curious, would this also then affect ArcaOS?
- agrover 3y agoI doubt it. This is probably talking about early versions of OS/2, like, pre-2.0.
- fredoralive 3y agoAccording to https://www.os2world.com/wiki/index.php/Databook_for_OS/2_%E2%80%93_Chapter_2_%E2%80%93_Inside_OS/2_Warp#Ring_Protection_mechanism https://www.os2world.com/wiki/index.php/Databook_for_OS/2_%E... OS/2 Warp 4 uses Rings 0, 2 and 3.
- bonzini 3y ago32-bit Xen also used ring 1.
- JdeBP 3y agoIf it's still using IBM code, then it definitely will. IBM's OS/2 kernel, even the 32-bit one from 2.0 onwards, had 16-bit code and the extra ring usage for IOPL. Then there's the fact that the rest of it is 32-bit. (-:
- creatonez 3y agoArcaOS is doomed, to put it mildly. Arca and eComStation were never given access to IBM source, so everything is bolted on through binary patching.
- lproven 3y agoHi. Article author here. Yes, it will. I am currently evaluating Arca OS. It currently does not run on UEFI machines anyway, although a version that can is in beta and they're getting a copy ready for me right now.
- xnx 3y agoIntel gets a lot of criticism for its management, and Apple get a lot of credit for the M1, but it's worth keeping in mind the tradeoffs/sacrifices for backward compatibility. I'm guessing Intel could create something radically more power efficient and performant if they gave up on decades worth of drop-in compatibility.
- microtonal 3y agoThat's fair. On the other hand, you can still run x86_64 applications on Apple Silicon through Rosetta. Sure, it's not 32-bit x86, but there are ways to provide backwards compatibility without supporting decades of legacy in hardware.
- deleted 3y ago[deleted]
- jeffbee 3y agoThat seems very unlikely. How much overhead do you believe there to be? Intel is about equal to apple silicon in performance and work per joule and per watt. If either of them could do much better, they would.
- brucethemoose2 3y ago> create something radically more power efficient Lots of the M1's efficiency comes from business decisions. Apple chooses to use an expensive, low clock TSMC node. They use a lot of expensive die area on wide cores and cache, so they can keep clocks and voltages (relatively) low. And they use packaged memory for efficiency, but at higher cost and with no modularity. Not saying it isn't a great design, but Intel/AMD could make a far more efficient CPU if they had the right market incentives to try. We have already seen a hint of this with Van Gogh (the Steam Deck chip) and their rumored "premium" laptop chips with big GPUs and an M1 Pro-like memory bus.
- tracker1 3y agoI don't know enough technically to comment on, but am curious how this plays into the mobile gaming device SOC/CPUs from AMD. I can say, really like my M1 air, generally good enough battery life and great i/o responsiveness in general. Of course, then I price out a M2 mini, and once I add enough storage/ram it's no longer feels worth the price. Why they even sell a model with under 512gb storage or 16gb memory other than to have a lower "starting from", and even getting to 1tb disk and 16gb or 32gb memory already feels like way too much of a price hike.
- nomoreusernames 3y ago[dead]
- MarkusWandel 3y agoThere are ancient 32-bit things that still run on modern operating systems, that you simply can't get a 64-bit version of. On my Linux machine, one specific such thing is the Brother printer driver. Brother laser printers are awesome. Cheap, reliable, inexpensive aftermarket toner etc. But to make them work (in my experience, and certainly for the scanner function) you need their binary driver and it has not (last I looked) been updated in years, and it's 32-bit. No problem, install the 32 bit compatibility libraries and go. On a pure 64 bit CPU, unless the 32-bit compatiblity problem is solved with emulation at the OS level, all this old 32-bit stuff is history. Or does "cutting 32-bit mode" not mean that, i.e. 32-bit binaries still run in the 64 bit mode?
- BaseballPhysics 3y ago> On a pure 64 bit CPU, unless the 32-bit compatiblity problem is solved with emulation at the OS level, all this old 32-bit stuff is history. And you've already answered your own question. Virtualization and emulation is precisely how this will be cared for. Heck, in a lot of cases, that's already how old 16- and 32-bit software is run, as you also need associated compatible operating systems, not to mention clock timings and so forth in the case of games, and it's a lot easier and more accurate to just fire up DOS or Windows 3.11 in a VM than to run the code natively with OS-level compatibility.
- Dwedit 3y ago32 bit windows software is not emulated, you call a 32-bit API function and it forwards to 64-bit mode at the system call level. Basically instead of SYSENTER you proceed back to 64-bit mode to perform the system call.
- fallat 3y agoTime to RE.
- markrages 3y agoThe traditional approach to proprietary printer drivers is to found a software movement that reimplements the entire operating system from scratch, and invent licenses that prevent distributors from keeping their changes to the system secret. This approach has been somewhat successful.
- kibwen 3y agoFor those wondering about the impact of removing 32-bit support: > It will still be possible to start up an x86-32 operating system inside a VM – these have to emulate system firmware in any case, alongside the emulated graphics cards, network cards and so on that they must provide. > You will also still be able to run x86-32 binaries and apps in ring three on your 64-bit OS in ring zero – so long as the operating system provides the appropriate libraries and APIs, of course.
- gavaw 3y agoI'm sure those options will be dog slow and unreliable. I buy wintel so I can run my software from 15 years ago without interference. Literally the only reason I don't buy a mac. If they want to take that away, well, good luck to them
- Sohcahtoa82 3y agoConsidering Intel is merely considering it at this stage means they're probably still several years away from actually releasing chips without 16/32-bit support. By that time, CPUs will be faster, and Intel will have had plenty of time to figure out the emulation layer. These days, how much performance-critical software is even being built in 32-bit?
- flaminHotSpeedo 3y ago> These days, how much performance-critical software is even being built in 32-bit? I think the better question is how much performance critical software built in 32 bit is still relied on, and may potentially outlive hardware with 32 bit support
- dzaima 3y agoIf it's old, even with emulation it'd have a good chance to be as fast or faster than on its original target chips. So you'd need to not only rely on it, but also be demanding more from it over time. And given that you're running 32-bit software in a 32-bit vm on a 64-bit cpu in the first place (in a scenario where you're spending significant amounts of time in ring 0!), you clearly do not really care about performance anyway.
- peterfirefly 3y agoIt is also about removing some I/O instructions entirely and removing all others from ring 3 ("userspace"). Removing 16-bit addressing support frees up the 67h address size override prefix. They also suggest having CS/DS/ES/SS segment override prefixes do the same as in 64-bit mode: nothing, which should allow for repurposing those 4 entries in the primary opcode map some years down the line. They are suggesting freeing up 5 bytes in primary opcode map in all modes (4 for string I/O, 1 for 67h address size override) plus 8 bytes in ring 3 (userspace) plus making it possible to free up 4 more (segment override prefixes). That means 13 (17) free bytes for userspace! I think part of the plan is to enable more compact encoding of certain existing instructions (and allow for compact encoding of future instructions). I think they want to do that to enable wider instruction decoders -- more compact encodings => more instructions per 16-byte/24-byte/32-byte/whatever size window the decoders look at. Wide decoders are inherently harder for x86 than for architectures like ARM because there are so many possible instruction lengths (all values between 1 and 15 inclusive), so they need all the juice they can squeeze out here. I am surprised they didn't suggest getting rid of the BOUND instruction (which is used for the EVEX prefix in 64-bit mode). And what about HLT? It isn't allowed in ring 3, anyway, so maybe they are looking at repurposing that as well? And INT1, too?
- dontlaugh 3y agoWider decoders seems like the most plausible motivation for this, yes.
- jcranmer 3y agoFrom what I can tell, they're not actually planning on reclaiming the opcode space. Instead, they're mapping those things to #UD, which allows a hypervisor to emulate those instructions for 32-bit guest OSes.
- peterfirefly 3y agoFor now, yes.
- layer8 3y agoPrevious discussion: https://news.ycombinator.com/item?id=36013257 https://news.ycombinator.com/item?id=36013257
- lproven 3y agoTrue but that was TH's story. This is a different one which I began writing before TH had published.
- GuB-42 3y agoThat's fine, but for me, it stops being x86 if it can't run legacy code. A 64-bit only CPU may be a sensible thing, and we can use emulators for old stuff, but when we are at it, do we really need x86 at all? If we are to break compatibility, couldn't we just switch to ARM, RISC-V, or something else? I mean, that's what Apple do, they did it successfully, and more than once (68k, PPC, x86, ARM), but Apple is Apple, and x86 is (was?) all about backwards compatibility.
- Dwedit 3y agoConfusingly, cutting out 32-bit mode does not break WOW64, and you can still run 32-bit applications. It keeps the ability to use the very simplified use of segmentation registers that Win32 programs use.