Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Intel Operating Systems

Intel Mulls Cutting Ties To 16 and 32-Bit Support (theregister.com) 239

Intel has proposed a potential simplification of the x86 architecture by creating a new x86S architecture that removes certain old features, such as 16-bit and some elements of 32-bit support. A technical note on Intel's developer blog proposes the change, with a 46-page white paper (PDF) providing more details. The Register reports: The result would be a family of processors which boot straight into x86-64 mode. That would mean bypassing the traditional series of transitions -- 16-bit real mode to 32-bit protected mode to 64-bit long mode; or 16-bit mode straight into 64-bit mode -- that chips are obliged to go through as the system starts up. [...] Some of the changes are quite dramatic, although the impact upon how most people use computers today would probably be invisible -- which is undoubtedly the idea.
This discussion has been archived. No new comments can be posted.

Intel Mulls Cutting Ties To 16 and 32-Bit Support

Comments Filter:
  • by DesScorp ( 410532 ) on Thursday May 25, 2023 @06:36PM (#63551339) Journal

    Backwards compatibility is one of the prime reasons why X86 has lasted so long. Even today, a tremendous amount of software is 32 bit. Intel would be eliminating one of the primary reasons people still use their chips.

    • by fahrbot-bot ( 874524 ) on Thursday May 25, 2023 @06:42PM (#63551347)

      Backwards compatibility is one of the prime reasons why X86 has lasted so long. Even today, a tremendous amount of software is 32 bit. Intel would be eliminating one of the primary reasons people still use their chips.

      TFS/A says they'd be creating a new family of 64-bit only processors, not (necessarily) eliminating others. If so, this might be good migration path. A more interesting bit from TFA, if this becomes the standard, is:

      Apart from eliminating 8086-style 16-bit real mode, and 80286-style 16-bit protected mode, it would also remove 32-bit ring zero, and completely remove protection rings one and two from the architecture.

      Just in case the distinction between the x86 protection rings has temporarily slipped your mind, we explained them and how they work in part one of our brief history of virtualization in 2011. Quickly though: ring zero is where an OS typically lives, and ring three is where apps run.

      • by Luckyo ( 1726890 )

        Doesn't that mean that 32-bit software would run fine, it's just that 32-bit OS would not?

        • Does seem to imply that they intend to keep basic ia32 decoding support in there.
          Seems like a good middle ground to start the transition.
          Windows has a pretty functional AOT+JIT solution for x86-32/64 -> aarch32/64 + library compat layer (i've played around with it on my Mac), so at the point where Intel+/-AMD (though I suspect both) decide to finally drop ia32 entirely, the only real concern will be the linux peeps. I don't think most of the Windows peeps will care about the 5% slowdown on the translat
    • I think this just means you can't run a 32-bit OS. Windows 11 no longer ships a 32-bit version which could be the cabalist for this change. The negative impact of this change will be minimal if any. I don't think this affects when you are booted in 64-bit mode; you wouldn't notice anything. This change could speed up boot times and lower chip prices.
      • This change could speed up boot times and lower chip prices.

        Faster and cheaper? Not sure I like where this is going [wikipedia.org] ... :-)

      • by AmiMoJo ( 196126 )

        Noooo how am I going to run FreeDOS now?!?

        I do wonder how much it will affect chip prices though. I don't think there is much silicon dedicated to those old features anymore, they are mostly just some extra microcode with no physical implementation at all. Performance of them doesn't matter because hardly anything uses them, and stuff that does is designed for much slower CPUs anyway.

    • Re: (Score:3, Interesting)

      by Narcocide ( 102829 )

      Remember that they already had tried to do this back in 2006 and it lead directly to AMD eating their lunch.

      • If you're referring to Itanium, the situation isn't all that similar: x86-64 has been the main PC instruction set for many years now, so 16-bit and 32-bit support is only necessary for legacy applications, which means that a performance hit from emulation will be far less of a problem, as users will likely have updated performance critical applications to 64-bit long ago. Translating x86 to x86-64 will be easier than translating it to a very different instruction set. Plus emulation technology in general is

        • The reason why AMD's 64-bit instruction set won out over Intel's though was specifically because it maintained compatibility whilst Intel's did not. And eventually Intel had to give up and switch to AMD's instruction set because people don't like when things break.

          Yes, it's just "legacy software" that you think can be easily written off until you run across a legacy app that you need to use. Or you discover that some call in an app that you use relies on some specific function that got removed as part of

        • Plus emulation technology in general is more advanced these days.

          Compare HAXM to QEMU and tell me you still think pure emulation is good enough & doesn't completely suck performance wise. There's a reason why VirtualBox and VMware can run x86 on x86 at 99.9% native speed, but PC emulators for ARM-based Android devices are basically nonexistent. Emulating an x86 PC on an ARM Android device would be about as performant as emulating a PC-XT on an Amiga (entirely via software) was. IE, "not even remotely close to being good enough".

          Back in 1986, a 7.15MHz Amiga 1000 coul

          • Translation layers (Rosetta2/WOW64) operate at very good performance using AOT+JIT.
            QEMU's TCG engine.... frankly sucks big ass.
            It's not entirely fair, because it has to worry about things that unprivileged translators don't, but even running in user mode, it's just not very good.
          • Back in 1986, a 7.15MHz Amiga 1000 could emulate a black & white Mac+ reasonably well, because most of the emulation involved native execution with occasional traps for the emulator to intervene.

            An Amiga emulating a Macintosh was faster than a Macintosh, because Apple created a graphics-only computer with no graphics acceleration. Apple used off the shelf hardware and it showed. But you did have to have enough spare RAM to hold the ROM AND run AmigaOS AND run MacOS...

    • by jonwil ( 467024 ) on Thursday May 25, 2023 @07:17PM (#63551415)

      This plan doesn't mean that the bits of 32-bit support that 64-bit OSs use to run 32-bit software are being removed, just the bits of 32 bit support needed to boot a 32 bit OS.

    • by sbszine ( 633428 )

      Backwards compatibility is one of the prime reasons why X86 has lasted so long. Even today, a tremendous amount of software is 32 bit. Intel would be eliminating one of the primary reasons people still use their chips.

      Apple completely dropped 32-bit support in 2019 and people got over it. You might be thinking 'well Apple has a small market share anyway', but they did the same thing on iOS in 2017 (the 'appocalypse') and there wasn't a mass exodus to Android. I think if Intel did this, developers would pretty quickly follow and they'd end up with an advantage over AMD a few years down the track.

      • Almost completely.

        Little known factoid: You could still ask Mach for a 32-bit code segment, and it would give it to you.
        Of course, macOS didn't ship with 32-libs, so what you could do with that 32-bit segment was limited. But it was used (for things like Crossover)
      • Binary compatibility doesn't matter as much as it used to. Way back when software cost a small fortune, you invested for the long haul. If you needed to switch from PC to Amiga, that was going to cost you big. These days we've grown accustomed to timely and free patches to keep software in line with the whims of the OS, not to mention cross platform licensing. I'm no fan of the cloud or subscription services but the benefit tends to be far more graceful transitions between platforms.

        When apple dropped 32bit

    • I don't know my emulators very well, but Apple seems to be able to run x86 on an Arm CPU (albeit a bit slowly) - surely then, Microsoft (or someone) should be able to run legacy, 32-bit compiled code on a 64 bit CPU at least as well, if not better than the original 32 bit CPU that it as compiled for?

      Granted, you won't be able to run a 32 bit OS on a 64 bit CPU, because there's no emulation layer to load the OS into. But that's surely a bit of a niche problem - and solved by VMs if you really need to do it.

  • "x86S" would not mean that 32-bit and 16-bit code couldn't run, it just means that it would have to run via virtualization. This really isn't a big deal. "Backwards-compatibility" won't necessarily be broken. We are quickly approaching an era where pretty much any code should be able to run on any CPU. Even running ARM programs on x86 is no big deal, again, because of virtualization. There doesn't need to be a direct link between the code and your CPU anymore. Being able to run 64-bit x86 code native
    • by Misagon ( 1135 ) on Thursday May 25, 2023 @07:33PM (#63551455)

      32-bit programs would still run under a 64-bit OS.

      16-bit programs could only run through emulation. Running them under a hypervisor would not be possible.

    • by Luckyo ( 1726890 )

      Virtualization requires hardware support for said instructions, so it would not be possible.

    • The word you’re looking for is emulation. Which wouldn’t be a problem anyhow because your modern CPU is so much faster than anything designed for a 16 or 32 bit cpu.

      • I have a bunch of games that only run under win98. I can't install win98 on modern hardware and vmware et al suck for gaming and so the only way to get them to work has been 86box. But on the best CPU I have 86box struggles to maintain the equivalent performance of a P166MMX. Some stuff plays nicer with the Dynareq than others, but it's not consistent. So, emulation is technically possible, but you won't be getting performance far beyond what the author got to witness, far from it. Not until better emulator
  • Amusing Timing. This came up as an ad on my phone the other day, and I thought, NT 4.0 ? Where am I, 1998? Who the hell is buying these machines for such a stupidly expensive price? - https://nixsys.com/ [nixsys.com]

    Seriously. NT 4.0

    • They even have Windows 98. I can't imagine the hell you're in if you're actually requesting a Win98 PC.
    • by darkjedi521 ( 744526 ) on Thursday May 25, 2023 @07:43PM (#63551481)
      People for whom a $2,000 NT4 compatible replacement system is cheaper than a $7,000,000 replacement electron microscope to eliminate the NT4 requirement.
      • And NT4 works as well as the first day the microscope was in use. But neither it or the machine it operates will work well with modern boards so that's why there is a demand for new (or new-old/refirbished stock) of the same era the rest of the equipment is from. And remanufacturing products there is no high demand in the consumer sector for is expensive.

      • If the electron microscope is that old, an equivalent replacement is probably going to be more like $100,000. Still cheaper to keep NT4 going, obvs.

    • Replacement boards for industrial machines that rely on proprietaty software that was written decades ago and that the vendor stopped supporting. Ditto for the interface cards for those machines so that's why you see ISA slot boards advertised on that site.

        This is why you have factory floors with machines running Windows 2000 or something about as old in this day and age.

    • Amusing Timing. This came up as an ad on my phone the other day, and I thought, NT 4.0 ? Where am I, 1998? Who the hell is buying these machines for such a stupidly expensive price? - https://nixsys.com/ [nixsys.com]

      Seriously. NT 4.0

      Clue: There's millions of expensive industrial machines out there being run by legacy Windows.

      (and a lot of cheap ones, too, eg. in automative diagnosis...)

  • "Mulls?" "Cutting ties to?" Are bloviators from the Economist writing for El Reg now? WTF?
    • by Lproven ( 6030 )

      Hi. I wrote the article.

      This is a *proposal*. It's not a plan or an announcement. They are thinking about it and this blog post and white paper are for discussion and to gauge reaction.

  • Yes but... (Score:4, Funny)

    by Virtucon ( 127420 ) on Thursday May 25, 2023 @07:41PM (#63551475)

    Would my Leisure Suit Larry Games on CD still work?

    • Wait... you have Leisure Suit Larry on CD, not floppy? (My lesbian friend used to love that game, by the way.)
    • Would my Leisure Suit Larry Games on CD still work?

      Most Likely not. Even if it is (mostly) a Win32 app, many programs and libraries of that era had snippets of 16 bit code, so no.

      Having said that, scummVM + the assets in the CD may do the trick

    • Would my Leisure Suit Larry Games on CD still work?

      Sure, just run them in DosBox;

  • If it's not compatible with every previous X86, then why am I using X86 architecture at all? Microsoft has an ARM64 based Windows 11 Surface laptop now, by the way, although the benchmarks make it look significantly slower than their Intel chip ones.
    • by Luckyo ( 1726890 )

      Because AMD64 crushes ARM at general compute, and most of AMD64 software is coded for that.

    • If it's not compatible with every previous X86, then why am I using X86 architecture at all? Microsoft has an ARM64 based Windows 11 Surface laptop now, by the way, although the benchmarks make it look significantly slower than their Intel chip ones.

      Because, most likely, you are not using 16bit 8086 or 286 OSs or SW, and most likely you are not using 32bit x86 OSs. Nowadays you are using 64Bit x86 OSs and SW, and 32Bit SW, and those will work fine under the new chips

    • If it's not compatible with every previous X86, then why am I using X86 architecture at all? ... benchmarks significantly slower than their Intel chip ones.

      You just answered your own question.

  • Especially the 16 bit. Maybe just use an emulator?

    • 16-bit real mode and v86 mode is hard to use from a 64-bit kernel, as you'd have to do a rather costly dance to bounce out of long mode. So everyone, as far as I know, uses 16-bit emulation if they support real mode code at all. Usually 16-bit code is still done on non-UEFI platforms to initialize text mode from the VGA BIOS, modern graphics cards are a little weird when it comes to getting the I/O port address space up and clocks setup for the correct head. And it's a bit of a chicken-and-egg if you put th

  • Think about that,

    emulation -> slow, but when you could transfer the datastream for computing on 16-bit and or 32-bit CPUs over a fast (pci.e in every of it's incarnations, should provide more than enough speed) interface to a co-processor providing fast in silicon execution, and perhaps intel would "dare" to build a special interface/instruction into it's processors for attaching those co-processors and use the system ram.

    Intel could beat two problems at once
    a.) main stream: make a slick unbloated 64-bit

  • The Register is a joke site.
    It is frequently inaccurate and never corrected.

    Please link to factual news sites.
    • by evanh ( 627108 )

      It makes fun of real news, sure. Particularly when the news is due to some douche-bag's actions. That doesn't make it inaccurate nor incorrect.

  • That seems to be a good idea, their CPU designs suck. Only keeping AMD64 is clearly the way forward.

Work is the crab grass in the lawn of life. -- Schulz

Working...