10 ms·

The Intel 80376 – A legacy-free i386 with a twist (2010)

102 points by anyfoo 4y ago

allenrb 4y ago
I'd forgotten about the 80376 but it hits at a question I've occasionally had over the last few years. Why have we not seen a "modernized" x86 CPU that strips out everything pre-AMD64? The answer seems likely to be one or both of: 1. There are more users of legacy modes than is obvious to us on HN. 2. The gains in terms of gate lost, critical paths reduced, lower power consumption just don't amount to much. My guess is that #2 is the dominant factor. If there were actually significant gains to be had on a "clean"(er) x86 design, we'd see it in the market regardless of #1.
- unnah 4y ago
  Instruction decoding is a bottleneck for x86 these days: Apple M1 can do 8-wide decode, Intel just managed to reach 6-wide in Alder Lake, and AMD Zen 3 only has a 4-wide decoder. One would think that dropping legacy 16-bit and 32-bit instructions would enable simpler and more efficient instruction decoders in future x86 versions.
  - amluto 4y ago
    Sadly not. x86_64’s encoding is extremely similar to the legacy encodings. AIUI the fundamental problem is that x86 is a variable-length encoding, so a fully parallel decoder needs to decode at guessed offsets, many of which will be wrong. ARM64 instructions are aligned. Dumping legacy features would be great for all kinds of reasons, but not this particular reason.
    - hyperman1 4y ago
      This suggests another way forward: Re-encode the existing opcodes with new, more regular byte sequences. E.g. 32 bits / instruction, with some escape for e.g. 64bit constants. You'll have to redo the backend of the assembler, but most of the compiler and optimization wisdom can be reused as-is. Of course, this breaks backward compatibility completely so the high performance mode can only be unlocked for recompiles.
      - colejohnson66 4y ago
        That was Itanium, and it failed for a variety of reasons; one of which was a compatibility layer that sucked. You can't get rid of x86's backwards compatibility. Intel and AMD have done their best by using vector prefixes (like VEX and EVEX)[a] that massively simplify decoding, but there's only so much that can be done. People get caught up in the variable length issue that x86 has, and then claim that M1 beats x86 because of that. Sure, decoding ARM instructions is easier than x86, but the variable length aspect is handled in the predecode/cache stage, not the actual decoder. The decoder, when it reaches an instruction, already knows various bits of info are. The RISC vs CISC debate is useless today. M1's big advantage comes from the memory ordering model (and other things)[0], not the instruction format. Apple actually had to create a special mode for the M1 (for Rosetta 2) that enforces the x86 ordering model (TSO with load forwarding), and native performance is slightly worse when doing so. [0]: https://twitter.com/ErrataRob/status/1331735383193903104 https://twitter.com/ErrataRob/status/1331735383193903104 [a]: There's also others that predate AVX (VEX) such as the 0F38 prefix group consisting only of opcodes that have a ModR/M byte and no immediate, and the 0F3A prefix being the same, but with an 8 bit immediate.
        kmeisthax 4y ago
        M1 doesn't have a special mode for Rosetta. All code is executed with x86 TSO on M1's application processors. How do I know this? Well, did you know Apple ported Rosetta 2 to Linux? You can get it by running a Linux VM on macOS. It does not require any kernel changes to support in VMs, and if you extract the binary to run it on Asahi Linux, it works just fine too. None of the Asahi team did anything to support x86 TSO. Rosetta also works just fine in m1n1's hypervisor mode, which exists specifically to log all hardware access to detect these sorts of things. If there is a hardware toggle for TSO, it's either part of the chicken bits (and thus enabled all the time anyway) or turned on by iBoot (and thus enabled before any user code runs). Related point: Hector Martin just upstreamed a patch to Linux that fixes a memory ordering bug in workqueues that's been around since before Linux had Git history. He also found a bug in some ARM litmus tests that he was using to validate whether or not they were implemented correctly. Both of those happened purely because M1 and M2 are so hilariously wide and speculative that they trigger memory reorders no other CPU would.
    - orionblastar 4y ago
      Legacy features are still needed for 16 bit DOS and Windows programs. You can cut out 16 bit legacy mode and use DOSBOX: https://www.dosbox.com/ https://www.dosbox.com/ for your 16 bit programs via emulation. There are those users who still want to use DOS programs: https://www.freedos.org/ https://www.freedos.org/
      - tinus_hn 4y ago
        Considering this ‘needed’ legacy application is running code made for a 8MHz processor, you can trivially get away with emulating that processor on the multi GHz CPU in a recent computer. By the way, 64 bit Windows doesn’t run 16 bits applications and never has. The only relevant 16 bit code is InstallShield and that is emulated using trickery. For the rest you need to emulate a whole computer. https://docs.microsoft.com/en-us/troubleshoot/windows-client/application-management/x64-windows-not-support-16-bit-programs https://docs.microsoft.com/en-us/troubleshoot/windows-client...
        amluto 4y ago
        But Linux does run 16-bit code natively, even on x86_64, via modify_ldt(). The kernel support is straightforward, and the user side is actively supported by DOSEMU2. Sadly, there was a serious design error in the original x86_64 support for i387 floating point, and it was never possible for a 64-bit kernel to correctly context switch some of the more obscure legacy floating point exception state. Rather than fixing it, both AMD and Intel nerfed the hardware support, and new CPUs no longer fully support this state. This makes some older 16-bit software work poorly.
        tinus_hn 4y ago
        Then again there is no 16 bit Linux software as there has never been 16 bit Linux, and 16-bit software for other operating systems is trivially emulated without requiring hardware support. It might all be somewhat of an interesting exercise but it doesn’t have real world value.
  - gabereiser 4y ago
    To someone who is interested in bare metal, can you explain the significance of this? Is this how much data a CPU can handle simultaneously? Via instructions from the kernel?
    - anyfoo 4y ago
      It means how many instructions the CPU can decode at the same time, roughly to "figure out what they mean and dispatch what they actually have to do to the functional units of the CPU which will perform the work of the instruction". It is not directly how much data a superscalar CPU can handle in parallel, but still plays a role, in the sense that there is a number of functional units available in the CPU, and if you cannot keep those busy with decoded instructions, then they lay around unused. So a too narrow decoder can be one of the bottlenecks in optimal CPU usage (but note how as a sibling commenter mentioned, the complexity of the instructions/architecture is also important, e.g. a single CISC instruction may keep things pretty busy by itself). Whether the instructions come from the kernel or from userspace does not matter at all, they all go through the same decoder and functional units. The kernel/userspace differentiation is a higher level concept.
  - monocasa 4y ago
    It's more complex than that if you'll excuse the pun. Instructions on CISC cores aren't 1 to 1 with RISC instructions, and tend to encode quite a bit more micro ops. Something like inc dword [rbp+16] is one instruction, but would be a minimum of three micro ops (and would be three RISC instructions as well). Long story short, this isn't really the bottle neck, or we'd see more simple decoders on the tail end of the decode window.
  - mhh__ 4y ago
    Decode bound performance issues are actually pretty rare. X86 is quite dense.
- Macha 4y ago
  As the article points out, modern x86 CPUs boot up in 16 bit mode, then get transferred into 32 bit mode, then 64 bit mode. So right out the gate such a CPU is not compatible with existing operating systems, so now you have a non-compatible architecture. Sure Intel could easily add support to GRUB and push Microsoft to do it for new Windows media, but that won't help the existing install base. Intel tried launching a non-compatible CPU once, it was Itanium, it didn't go so well for them. Plus I'm sure there's crazy DRM rootkits that depend on these implementation details. Also, AMD has experimented with not-quite-PC-compatible x86 setups already in the consoles. As the fail0verflow talk about Linux on PS4 emphasised, the PS4 is x86, but not a PC. So despite building a x86 CPU with some less legacy, AMD didn't seem to think it worthwhile bringing it to a more general purpose platform Also AMD/Intel/VIA are the only companies with the licenses to produce x86, and you'd need both Intel and AMD to sign off on licensing x64 to someone new.
  - messe 4y ago
    > As the article points out, modern x86 CPUs boot up in 16 bit mode, then get transferred into 32 bit mode, then 64 bit mode. So right out the gate such a CPU is not compatible with existing operating systems, so now you have a non-compatible architecture Except that a modern OS is booted in UEFI mode meaning that the steps of going fro 16 -> 32 -> 64-bit mode are all handled by the firmware, not the kernel or the bootloader. The OS kernel will only (at most) switch to 32-bit compatibility mode (a submode of long-mode not protected mode) when it needs to run 32-bit apps, otherwise staying in 64-bit mode 100% of the time.
    - anyfoo 4y ago
      Yeah. Long mode is a bit of a line in the sand, leaving many features behind that were kept for compatibility (segmentation, vm86...). It came at a time where, fortunately, the mainstream OSes had enough abstraction so that software did not have to be written for what effectively was the bare metal anymore, with DOS almost being more of a "software bootloader with filesystem services".
  - anyfoo 4y ago
    > Intel tried launching a non-compatible CPU once, it was Itanium, it didn't go so well for them. That may be only secondary, though. Itanium simply failed to deliver performance promises and be competitive. The compiler was supposed to effectively perform instruction scheduling itself, and writing such a compiler turned out more difficult than anticipated.
- rwmj 4y ago
  Quite a lot of modern Arm 64 bit processors have dropped 32 bit (ie. ARMv7) support. Be careful what you wish for though! It's still useful to be able to run 32 bit i386 code at a decent speed occasionally. Even on my Linux systems I still have hundreds of *.i686.rpms installed.
  - jleahy 4y ago
    The 64-bit ARM instructions were designed in a way that made supporting both modes in parallel very expensive from a silicon perspective. In contrast AMD were very clever with AMD64 and designed it such that very little additional silicon area was required to add it.
  - repiret 4y ago
    Citation needed. I'm told that Apple-designed cores have indeed dropped AArch32, and AFAIK, no others have. I don't think its fair to call "only the ones designed by Apple" "quite a lot". The Cortex-A78 generation of Arm cores was the first set of Arm-designed cores that didn't support AArch32 at EL3, and they retain AArch32 support at EL0, even the N1 and X1. The early APM designed ARMv8 cores supported AArch32 at (at least) EL0, although I haven't kept up with that lineage. I haven't seen an nVidia-designed ARMv8 that dropped AArch32, although I also haven't worked with some of the newer ones. I suspect that maintaining support at EL0 is very cheap, because it can be done entirely in the instruction decoder.
    - garaetjjte 4y ago
      There probably won't be any new high-performance cores supporting AArch32. It's already gone from Cortex-X2, Cortex-X3, Cortex-A715.
    - octoberfranklin 4y ago
      Cavium dropped Arm32 support in 2014: "Only the 64-bit AArch64 execution state is support. No 32-bit AArch32 support" https://en.wikichip.org/wiki/cavium/thunderx https://en.wikichip.org/wiki/cavium/thunderx Qualcomm dropped Arm32 in Falkor, which shipped in 2017: "AArch64 only" https://en.wikichip.org/wiki/qualcomm/microarchitectures/falkor https://en.wikichip.org/wiki/qualcomm/microarchitectures/fal... Arm64 is really a wild and radical departure from Arm32, they're night-and-day different which is why dumping 32-bit support is attractive. Compare this with x86 where you have a microcode backdoor^H^H^Hengine to smooth over the differences, or POWER64/MIPS64 which built off of very clean 32-bit designs and stayed true to them. And of course RISC-V is the non-trademark-infringing name for MIPS-VI.
- tenebrisalietum 4y ago
  So I learned about the "hidden" x86 mode called XuCode (https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/secure-coding/xucode-implementing-complex-instruction-flows.html https://www.intel.com/content/www/us/en/developer/articles/t...) - which is x86 binary code placed into RAM by the microcode and then "called" by the microcode for certain instructions - particularly SGX ones if I'm remembering correctly. Wild speculative guess: It's entirely possible some of the pre-AMD64 stuff is actually internally used by modern Intel and AMD CPUs to implement complex instructions.
  - kmeisthax 4y ago
    Oh boy, we've gone all the way back to Transmeta Code Morphing Software. What "ring" does this live on now? Ring -4? :P Jokes aside, I doubt XuCode would use pre-AMD64 stuff; microcode is lower-level than that. The pre-AMD64 stuff is already handled with sequences of microcode operations because it's not really useful for modern applications[0]. It's entirely possible for microcode to implement other instructions too, and that's what XuCode is doing[1]. The real jank is probably hiding in early boot and SMM, because you need to both jump to modern execution modes for client or server machines and downgrade to BIOS compatibility for all those industrial deployments that want to run ancient software and OSes on modern machines. [0] The last time I heard someone even talk about x86 segmentation, it was as part of enforcing the Native Client inner sandbox. [1] Hell, there's no particular reason why you can't have a dual-mode CPU with separate decoders for ARM and x86 ISAs. As far as I'm aware, however, such a thing does not exist... though evidently at one point AMD was intending on shipping Ryzen CPUs with ARM decoders in them.
- klelatti 4y ago
  x86 did appear in one context where legacy compatibility is likely to have been a much smaller (or non issue?) and where (eg power consumption) efficiencies would have been even more valuable - that’s on mobile running Android. The fact that a cleaned version wasn’t used would seem to support your hypothesis.
- danbolt 4y ago
  I feel as though a lot of the consumer value of x86+Windows comes from its wide library of software and compatibility. > than is obvious to us on HN I think your average HNer is more likely to interact with Linux/Mac workstations or servers, where binary compatibility isn't as necessary.
  - Dalewyn 4y ago
    This. There is a reason Win32 foiled every single attempt from Microsoft to kill it, and a reason Intel has consistently failed to successfully market anything besides x86 processors. The reason is the PC world at large is a mountain of x86 and Win32 code piled sky high by decades of developers and users. Replacing all that takes money and time that nobody wants to spend, and chances are the replacement won't be a 1:1 drop-in replacement either which will necessitate further money and time nobody wants to spend. The average computer enthusiast might scoff at being able to run half-a-century old x86/Win32 code and binaries on modern hardware. Professionals consider that backwards compatibility their literal lifeblood and will pay handsomely to ensure nobody violates it (and refuse to pay anyone who does). I expect the ARM world will also be singing a similar tune in several decades' time, when backwards compatibility with ancient ARM binaries become steadily more important than pursuing the next new shiny at any cost.
    - anyfoo 4y ago
      Things change. Windows cut out 16-bit code with 64-bit Windows, so that particular half of the last "half century" is gone. Macs transitionedto different architectures several times, iPhones to some extend too (from armv7 to armv8, dropping arm32 support entirely relatively early after). The various Rosettas, most recently the x86-to-ARM one, showed that software emulation is always an option, and so does WoW64, which is a part of ARM Windows (and a part of x86-64 Windows, but there it's not really a software emulator). > I expect the ARM world will also be singing a similar tune in several decades' time, when backwards compatibility with ancient ARM binaries become steadily more important than pursuing the next new shiny at any cost. I am not so sure at all about that. The reason is that half to a quarter decade ago, even normal application code was very close to the metal, with MS-DOS basically being a glorified bootloader with file system services that loaded little mini-OSes calling themselves DOS applications. We are far, far away from that world. Mature abstractions make ISA transitions more and more painless for end-user application developers. The exponential advances in speed make software emulation well feasible for the remainder. High-performance stuff will want to take advantage of the new architectures anyway.
- rodgerd 4y ago
  Think about the disruption that Apple caused when they moved from 32-bit x86 being supported to deprecating it - there was a great deal of angst, and that's on a vertically-integrated platform that is relatively young (yes, I know that NeXT is old, but MacOS isn't, really). Now imagine that on Windows - a much older platform, with much higher expectations for backwards compat. It would be a bloodbath of user rage. More importantly, though, backward compat has been Intel's moat for a long, long time. Intel have been trying to get people to buy non-16-bit-compat processors for literally 40 years! They've tried introducing a lot of mildly (StrongARM - technically a buy I suppose, i860/i960) and radically (i432, Itanium) innovative processors, and they've all been indifferent or outright failures in the marketplace. The market has been really clear on this: it doesn't care for Intel graphics cards or SSDs or memory, it hates non-x86 Intel processors. Intel stays in business by shipping 16-bit-compatible processors.
- rbanffy 4y ago
  > Why have we not seen a "modernized" x86 CPU that strips out everything pre-AMD64? In many segments, binary compatibility with legacy software is still vital. This is why you can run Windows 3 software on Windows 11 (and why you can run x86 software on M1 Macs). For me, I could spend most of my time on Linux and there binary compatibility is a much smaller issue - I'm sure I'd be very happy with a POWER workstation (birthday is in March, Raptor folks) and perfectly functional there. Same on ARM (biggest constraint for me is memory - 16 GB is enough, 32 is good). Unless I look too closely, the CPU in the box is the least important part.
  - nl 4y ago
    > and why you can run x86 software on M1 Macs Seems like a pretty good case for the counterargument: that backwards compatibility can be entirely provided for in software. (To be clear, the M1 chip doesn't support the x86 instruction set at all, and translation is done entirely in software. I don't think there was ever any 16 bit x86 Mac software though, so not sure if that mode is supported).
    - toast0 4y ago
      The M1 chip does support the x86 memory ordering, which allows the software instruction set emulation to not have to do memory ordering work in software. I don't think Macs ever had 16-bit code? 68000 was 32-bit, as was ppc and intel macs were 32-bit to start, with 64-bit later.
      - nl 4y ago
        > I don't think Macs ever had 16-bit code? Yeah pretty sure you are right. > 68000 was 32-bit, Interestingly I discovered today the 68008 which was a 68000 with an 8-bit external data bus.
      - JonathonW 4y ago
        The original 68k (used in the original 1984 Mac) was funky: it had a fully 32-bit instruction set and 32-bit registers, but 16-bit internal and external data buses and a 16-bit ALU. And a 24-bit address bus, because reasons? Later variants of the 68k family were fully 32-bit internally, but exactly what was exposed externally varied by processor and Mac model. And 24-bit addressing remained a thing in the Macintosh system software up until System 7-- this capped RAM at 8 MB even if the CPU could handle more. But Apple never really had the same sort of 16-bit/32-bit transition that Microsoft and Intel did. The 68k-to-PPC shift is kind of analogous (and happened at around the same time as Microsoft was going fully 32-bit), but backwards compatibility there was purely based around software emulation-- same basic approach as Apple's PPC-to-x86 and x64-to-ARM transitions, as opposed to Intel's "just make the new processor a superset of the old one" approach.
- yarg 4y ago
  Why not both? Apple's proven it feasible to provide high performance emulation of a prior ISA. https://en.wikipedia.org/wiki/Rosetta_(software) https://en.wikipedia.org/wiki/Rosetta_(software)
- cat_plus_plus 4y ago
  If you already broke compatibility, might as well go all the way and optimize for your problem domain, such as graphics/AI/low power. And in fact GPUs/TPUs/ARM are doing very well, and there is a strong interest in quantum computing. So this leaves conventional high power, non-vector, core speed over concurrency computing, where you additionally expect existing operating systems and software ported and optimized for your architecture. Plus IBM Power PC mainframes and Apple ARM laptops don't fit the bill. There might just not be enough demand for such a product right now and if there is in future, someone will offer a solution?
johnklos 4y ago
> The 80376 doesn’t do paging. Wait - what? How is that even possible? Do they simply not have an MMU? That makes it unsuitable for both old OSes and for new OSes. No wonder it was so uncommon.
- anyfoo 4y ago
  It claims itself as an "embedded" processor, so it likely just wasn't meant to run PC OSes. According to Wikipedia at least, Intel did not even expect the 286 to be used for PCs, but for things such as PBXs. And ARM Cortex M still doesn't have an MMU either, for some applications you can just do without. Especially because both the 286 and this 376 beast did have segmentation, which could subsume some of the need for an MMU (separated address spaces, if you don't need paging and are content with e.g. buddy allocation for dividing available memory among tasks).
  - deleted 4y ago
    [deleted]
- marssaxman 4y ago
  It is very common for embedded systems processors not to have an MMU. If it ran any OS at all it would likely have been some kind of RTOS.
- blueflow 4y ago
  Using paging/virtual memory is not a requirement for an OS, even when all currently popular OSes make use of it. Intel CPUs before the 80286 did not have an MMU, either.
  - anyfoo 4y ago
    Did they even call it an MMU already? The 286 only had segmentation, which arguably is just an addressing mode. It introduced descriptors that had to be resolved, but that happened when selecting the descriptor (i.e. when loading the segment register), where a hidden base, limit, and permission "cache" was updated. Unlike paging, where things are resolved when accessing memory.
kazinator 4y ago
0x80386 - 16 = 0x80376 :)
zymhan 4y ago
Since the page is loading slowly, an archive link: http://web.archive.org/web/20220816012342/https://www.pagetable.com/?p=460 http://web.archive.org/web/20220816012342/https://www.pageta...

102 points by anyfoo 4y ago

I'd forgotten about the 80376 but it hits at a question I've occasionally had over the last few years. Why have we not seen a "modernized" x86 CPU that strips out everything pre-AMD64? The answer seems likely to be one or both of: 1. There are more users of legacy modes than is obvious to us on HN. 2. The gains in terms of gate lost, critical paths reduced, lower power consumption just don't amount to much. My guess is that #2 is the dominant factor. If there were actually significant gains to be had on a "clean"(er) x86 design, we'd see it in the market regardless of #1.

unnah 4y ago
Instruction decoding is a bottleneck for x86 these days: Apple M1 can do 8-wide decode, Intel just managed to reach 6-wide in Alder Lake, and AMD Zen 3 only has a 4-wide decoder. One would think that dropping legacy 16-bit and 32-bit instructions would enable simpler and more efficient instruction decoders in future x86 versions.
- amluto 4y ago
  Sadly not. x86_64’s encoding is extremely similar to the legacy encodings. AIUI the fundamental problem is that x86 is a variable-length encoding, so a fully parallel decoder needs to decode at guessed offsets, many of which will be wrong. ARM64 instructions are aligned. Dumping legacy features would be great for all kinds of reasons, but not this particular reason.
  - hyperman1 4y ago
    This suggests another way forward: Re-encode the existing opcodes with new, more regular byte sequences. E.g. 32 bits / instruction, with some escape for e.g. 64bit constants. You'll have to redo the backend of the assembler, but most of the compiler and optimization wisdom can be reused as-is. Of course, this breaks backward compatibility completely so the high performance mode can only be unlocked for recompiles.
    - colejohnson66 4y ago
      That was Itanium, and it failed for a variety of reasons; one of which was a compatibility layer that sucked. You can't get rid of x86's backwards compatibility. Intel and AMD have done their best by using vector prefixes (like VEX and EVEX)[a] that massively simplify decoding, but there's only so much that can be done. People get caught up in the variable length issue that x86 has, and then claim that M1 beats x86 because of that. Sure, decoding ARM instructions is easier than x86, but the variable length aspect is handled in the predecode/cache stage, not the actual decoder. The decoder, when it reaches an instruction, already knows various bits of info are. The RISC vs CISC debate is useless today. M1's big advantage comes from the memory ordering model (and other things)[0], not the instruction format. Apple actually had to create a special mode for the M1 (for Rosetta 2) that enforces the x86 ordering model (TSO with load forwarding), and native performance is slightly worse when doing so. [0]: https://twitter.com/ErrataRob/status/1331735383193903104 https://twitter.com/ErrataRob/status/1331735383193903104 [a]: There's also others that predate AVX (VEX) such as the 0F38 prefix group consisting only of opcodes that have a ModR/M byte and no immediate, and the 0F3A prefix being the same, but with an 8 bit immediate.
      - kmeisthax 4y ago
        M1 doesn't have a special mode for Rosetta. All code is executed with x86 TSO on M1's application processors. How do I know this? Well, did you know Apple ported Rosetta 2 to Linux? You can get it by running a Linux VM on macOS. It does not require any kernel changes to support in VMs, and if you extract the binary to run it on Asahi Linux, it works just fine too. None of the Asahi team did anything to support x86 TSO. Rosetta also works just fine in m1n1's hypervisor mode, which exists specifically to log all hardware access to detect these sorts of things. If there is a hardware toggle for TSO, it's either part of the chicken bits (and thus enabled all the time anyway) or turned on by iBoot (and thus enabled before any user code runs). Related point: Hector Martin just upstreamed a patch to Linux that fixes a memory ordering bug in workqueues that's been around since before Linux had Git history. He also found a bug in some ARM litmus tests that he was using to validate whether or not they were implemented correctly. Both of those happened purely because M1 and M2 are so hilariously wide and speculative that they trigger memory reorders no other CPU would.
  - orionblastar 4y ago
    Legacy features are still needed for 16 bit DOS and Windows programs. You can cut out 16 bit legacy mode and use DOSBOX: https://www.dosbox.com/ https://www.dosbox.com/ for your 16 bit programs via emulation. There are those users who still want to use DOS programs: https://www.freedos.org/ https://www.freedos.org/
    - tinus_hn 4y ago
      Considering this ‘needed’ legacy application is running code made for a 8MHz processor, you can trivially get away with emulating that processor on the multi GHz CPU in a recent computer. By the way, 64 bit Windows doesn’t run 16 bits applications and never has. The only relevant 16 bit code is InstallShield and that is emulated using trickery. For the rest you need to emulate a whole computer. https://docs.microsoft.com/en-us/troubleshoot/windows-client/application-management/x64-windows-not-support-16-bit-programs https://docs.microsoft.com/en-us/troubleshoot/windows-client...
      - amluto 4y ago
        But Linux does run 16-bit code natively, even on x86_64, via modify_ldt(). The kernel support is straightforward, and the user side is actively supported by DOSEMU2. Sadly, there was a serious design error in the original x86_64 support for i387 floating point, and it was never possible for a 64-bit kernel to correctly context switch some of the more obscure legacy floating point exception state. Rather than fixing it, both AMD and Intel nerfed the hardware support, and new CPUs no longer fully support this state. This makes some older 16-bit software work poorly.
        tinus_hn 4y ago
        Then again there is no 16 bit Linux software as there has never been 16 bit Linux, and 16-bit software for other operating systems is trivially emulated without requiring hardware support. It might all be somewhat of an interesting exercise but it doesn’t have real world value.
- gabereiser 4y ago
  To someone who is interested in bare metal, can you explain the significance of this? Is this how much data a CPU can handle simultaneously? Via instructions from the kernel?
  - anyfoo 4y ago
    It means how many instructions the CPU can decode at the same time, roughly to "figure out what they mean and dispatch what they actually have to do to the functional units of the CPU which will perform the work of the instruction". It is not directly how much data a superscalar CPU can handle in parallel, but still plays a role, in the sense that there is a number of functional units available in the CPU, and if you cannot keep those busy with decoded instructions, then they lay around unused. So a too narrow decoder can be one of the bottlenecks in optimal CPU usage (but note how as a sibling commenter mentioned, the complexity of the instructions/architecture is also important, e.g. a single CISC instruction may keep things pretty busy by itself). Whether the instructions come from the kernel or from userspace does not matter at all, they all go through the same decoder and functional units. The kernel/userspace differentiation is a higher level concept.
- monocasa 4y ago
  It's more complex than that if you'll excuse the pun. Instructions on CISC cores aren't 1 to 1 with RISC instructions, and tend to encode quite a bit more micro ops. Something like inc dword [rbp+16] is one instruction, but would be a minimum of three micro ops (and would be three RISC instructions as well). Long story short, this isn't really the bottle neck, or we'd see more simple decoders on the tail end of the decode window.
- mhh__ 4y ago
  Decode bound performance issues are actually pretty rare. X86 is quite dense.
Macha 4y ago
As the article points out, modern x86 CPUs boot up in 16 bit mode, then get transferred into 32 bit mode, then 64 bit mode. So right out the gate such a CPU is not compatible with existing operating systems, so now you have a non-compatible architecture. Sure Intel could easily add support to GRUB and push Microsoft to do it for new Windows media, but that won't help the existing install base. Intel tried launching a non-compatible CPU once, it was Itanium, it didn't go so well for them. Plus I'm sure there's crazy DRM rootkits that depend on these implementation details. Also, AMD has experimented with not-quite-PC-compatible x86 setups already in the consoles. As the fail0verflow talk about Linux on PS4 emphasised, the PS4 is x86, but not a PC. So despite building a x86 CPU with some less legacy, AMD didn't seem to think it worthwhile bringing it to a more general purpose platform Also AMD/Intel/VIA are the only companies with the licenses to produce x86, and you'd need both Intel and AMD to sign off on licensing x64 to someone new.
- messe 4y ago
  > As the article points out, modern x86 CPUs boot up in 16 bit mode, then get transferred into 32 bit mode, then 64 bit mode. So right out the gate such a CPU is not compatible with existing operating systems, so now you have a non-compatible architecture Except that a modern OS is booted in UEFI mode meaning that the steps of going fro 16 -> 32 -> 64-bit mode are all handled by the firmware, not the kernel or the bootloader. The OS kernel will only (at most) switch to 32-bit compatibility mode (a submode of long-mode not protected mode) when it needs to run 32-bit apps, otherwise staying in 64-bit mode 100% of the time.
  - anyfoo 4y ago
    Yeah. Long mode is a bit of a line in the sand, leaving many features behind that were kept for compatibility (segmentation, vm86...). It came at a time where, fortunately, the mainstream OSes had enough abstraction so that software did not have to be written for what effectively was the bare metal anymore, with DOS almost being more of a "software bootloader with filesystem services".
- anyfoo 4y ago
  > Intel tried launching a non-compatible CPU once, it was Itanium, it didn't go so well for them. That may be only secondary, though. Itanium simply failed to deliver performance promises and be competitive. The compiler was supposed to effectively perform instruction scheduling itself, and writing such a compiler turned out more difficult than anticipated.
rwmj 4y ago
Quite a lot of modern Arm 64 bit processors have dropped 32 bit (ie. ARMv7) support. Be careful what you wish for though! It's still useful to be able to run 32 bit i386 code at a decent speed occasionally. Even on my Linux systems I still have hundreds of *.i686.rpms installed.
- jleahy 4y ago
  The 64-bit ARM instructions were designed in a way that made supporting both modes in parallel very expensive from a silicon perspective. In contrast AMD were very clever with AMD64 and designed it such that very little additional silicon area was required to add it.
- repiret 4y ago
  Citation needed. I'm told that Apple-designed cores have indeed dropped AArch32, and AFAIK, no others have. I don't think its fair to call "only the ones designed by Apple" "quite a lot". The Cortex-A78 generation of Arm cores was the first set of Arm-designed cores that didn't support AArch32 at EL3, and they retain AArch32 support at EL0, even the N1 and X1. The early APM designed ARMv8 cores supported AArch32 at (at least) EL0, although I haven't kept up with that lineage. I haven't seen an nVidia-designed ARMv8 that dropped AArch32, although I also haven't worked with some of the newer ones. I suspect that maintaining support at EL0 is very cheap, because it can be done entirely in the instruction decoder.
  - garaetjjte 4y ago
    There probably won't be any new high-performance cores supporting AArch32. It's already gone from Cortex-X2, Cortex-X3, Cortex-A715.
  - octoberfranklin 4y ago
    Cavium dropped Arm32 support in 2014: "Only the 64-bit AArch64 execution state is support. No 32-bit AArch32 support" https://en.wikichip.org/wiki/cavium/thunderx https://en.wikichip.org/wiki/cavium/thunderx Qualcomm dropped Arm32 in Falkor, which shipped in 2017: "AArch64 only" https://en.wikichip.org/wiki/qualcomm/microarchitectures/falkor https://en.wikichip.org/wiki/qualcomm/microarchitectures/fal... Arm64 is really a wild and radical departure from Arm32, they're night-and-day different which is why dumping 32-bit support is attractive. Compare this with x86 where you have a microcode backdoor^H^H^Hengine to smooth over the differences, or POWER64/MIPS64 which built off of very clean 32-bit designs and stayed true to them. And of course RISC-V is the non-trademark-infringing name for MIPS-VI.
tenebrisalietum 4y ago
So I learned about the "hidden" x86 mode called XuCode (https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/secure-coding/xucode-implementing-complex-instruction-flows.html https://www.intel.com/content/www/us/en/developer/articles/t...) - which is x86 binary code placed into RAM by the microcode and then "called" by the microcode for certain instructions - particularly SGX ones if I'm remembering correctly. Wild speculative guess: It's entirely possible some of the pre-AMD64 stuff is actually internally used by modern Intel and AMD CPUs to implement complex instructions.
- kmeisthax 4y ago
  Oh boy, we've gone all the way back to Transmeta Code Morphing Software. What "ring" does this live on now? Ring -4? :P Jokes aside, I doubt XuCode would use pre-AMD64 stuff; microcode is lower-level than that. The pre-AMD64 stuff is already handled with sequences of microcode operations because it's not really useful for modern applications[0]. It's entirely possible for microcode to implement other instructions too, and that's what XuCode is doing[1]. The real jank is probably hiding in early boot and SMM, because you need to both jump to modern execution modes for client or server machines and downgrade to BIOS compatibility for all those industrial deployments that want to run ancient software and OSes on modern machines. [0] The last time I heard someone even talk about x86 segmentation, it was as part of enforcing the Native Client inner sandbox. [1] Hell, there's no particular reason why you can't have a dual-mode CPU with separate decoders for ARM and x86 ISAs. As far as I'm aware, however, such a thing does not exist... though evidently at one point AMD was intending on shipping Ryzen CPUs with ARM decoders in them.
klelatti 4y ago
x86 did appear in one context where legacy compatibility is likely to have been a much smaller (or non issue?) and where (eg power consumption) efficiencies would have been even more valuable - that’s on mobile running Android. The fact that a cleaned version wasn’t used would seem to support your hypothesis.
danbolt 4y ago
I feel as though a lot of the consumer value of x86+Windows comes from its wide library of software and compatibility. > than is obvious to us on HN I think your average HNer is more likely to interact with Linux/Mac workstations or servers, where binary compatibility isn't as necessary.
- Dalewyn 4y ago
  This. There is a reason Win32 foiled every single attempt from Microsoft to kill it, and a reason Intel has consistently failed to successfully market anything besides x86 processors. The reason is the PC world at large is a mountain of x86 and Win32 code piled sky high by decades of developers and users. Replacing all that takes money and time that nobody wants to spend, and chances are the replacement won't be a 1:1 drop-in replacement either which will necessitate further money and time nobody wants to spend. The average computer enthusiast might scoff at being able to run half-a-century old x86/Win32 code and binaries on modern hardware. Professionals consider that backwards compatibility their literal lifeblood and will pay handsomely to ensure nobody violates it (and refuse to pay anyone who does). I expect the ARM world will also be singing a similar tune in several decades' time, when backwards compatibility with ancient ARM binaries become steadily more important than pursuing the next new shiny at any cost.
  - anyfoo 4y ago
    Things change. Windows cut out 16-bit code with 64-bit Windows, so that particular half of the last "half century" is gone. Macs transitionedto different architectures several times, iPhones to some extend too (from armv7 to armv8, dropping arm32 support entirely relatively early after). The various Rosettas, most recently the x86-to-ARM one, showed that software emulation is always an option, and so does WoW64, which is a part of ARM Windows (and a part of x86-64 Windows, but there it's not really a software emulator). > I expect the ARM world will also be singing a similar tune in several decades' time, when backwards compatibility with ancient ARM binaries become steadily more important than pursuing the next new shiny at any cost. I am not so sure at all about that. The reason is that half to a quarter decade ago, even normal application code was very close to the metal, with MS-DOS basically being a glorified bootloader with file system services that loaded little mini-OSes calling themselves DOS applications. We are far, far away from that world. Mature abstractions make ISA transitions more and more painless for end-user application developers. The exponential advances in speed make software emulation well feasible for the remainder. High-performance stuff will want to take advantage of the new architectures anyway.
rodgerd 4y ago
Think about the disruption that Apple caused when they moved from 32-bit x86 being supported to deprecating it - there was a great deal of angst, and that's on a vertically-integrated platform that is relatively young (yes, I know that NeXT is old, but MacOS isn't, really). Now imagine that on Windows - a much older platform, with much higher expectations for backwards compat. It would be a bloodbath of user rage. More importantly, though, backward compat has been Intel's moat for a long, long time. Intel have been trying to get people to buy non-16-bit-compat processors for literally 40 years! They've tried introducing a lot of mildly (StrongARM - technically a buy I suppose, i860/i960) and radically (i432, Itanium) innovative processors, and they've all been indifferent or outright failures in the marketplace. The market has been really clear on this: it doesn't care for Intel graphics cards or SSDs or memory, it hates non-x86 Intel processors. Intel stays in business by shipping 16-bit-compatible processors.
rbanffy 4y ago
> Why have we not seen a "modernized" x86 CPU that strips out everything pre-AMD64? In many segments, binary compatibility with legacy software is still vital. This is why you can run Windows 3 software on Windows 11 (and why you can run x86 software on M1 Macs). For me, I could spend most of my time on Linux and there binary compatibility is a much smaller issue - I'm sure I'd be very happy with a POWER workstation (birthday is in March, Raptor folks) and perfectly functional there. Same on ARM (biggest constraint for me is memory - 16 GB is enough, 32 is good). Unless I look too closely, the CPU in the box is the least important part.
- nl 4y ago
  > and why you can run x86 software on M1 Macs Seems like a pretty good case for the counterargument: that backwards compatibility can be entirely provided for in software. (To be clear, the M1 chip doesn't support the x86 instruction set at all, and translation is done entirely in software. I don't think there was ever any 16 bit x86 Mac software though, so not sure if that mode is supported).
  - toast0 4y ago
    The M1 chip does support the x86 memory ordering, which allows the software instruction set emulation to not have to do memory ordering work in software. I don't think Macs ever had 16-bit code? 68000 was 32-bit, as was ppc and intel macs were 32-bit to start, with 64-bit later.
    - nl 4y ago
      > I don't think Macs ever had 16-bit code? Yeah pretty sure you are right. > 68000 was 32-bit, Interestingly I discovered today the 68008 which was a 68000 with an 8-bit external data bus.
    - JonathonW 4y ago
      The original 68k (used in the original 1984 Mac) was funky: it had a fully 32-bit instruction set and 32-bit registers, but 16-bit internal and external data buses and a 16-bit ALU. And a 24-bit address bus, because reasons? Later variants of the 68k family were fully 32-bit internally, but exactly what was exposed externally varied by processor and Mac model. And 24-bit addressing remained a thing in the Macintosh system software up until System 7-- this capped RAM at 8 MB even if the CPU could handle more. But Apple never really had the same sort of 16-bit/32-bit transition that Microsoft and Intel did. The 68k-to-PPC shift is kind of analogous (and happened at around the same time as Microsoft was going fully 32-bit), but backwards compatibility there was purely based around software emulation-- same basic approach as Apple's PPC-to-x86 and x64-to-ARM transitions, as opposed to Intel's "just make the new processor a superset of the old one" approach.
yarg 4y ago
Why not both? Apple's proven it feasible to provide high performance emulation of a prior ISA. https://en.wikipedia.org/wiki/Rosetta_(software) https://en.wikipedia.org/wiki/Rosetta_(software)
cat_plus_plus 4y ago
If you already broke compatibility, might as well go all the way and optimize for your problem domain, such as graphics/AI/low power. And in fact GPUs/TPUs/ARM are doing very well, and there is a strong interest in quantum computing. So this leaves conventional high power, non-vector, core speed over concurrency computing, where you additionally expect existing operating systems and software ported and optimized for your architecture. Plus IBM Power PC mainframes and Apple ARM laptops don't fit the bill. There might just not be enough demand for such a product right now and if there is in future, someone will offer a solution?

johnklos 4y ago

> The 80376 doesn’t do paging. Wait - what? How is that even possible? Do they simply not have an MMU? That makes it unsuitable for both old OSes and for new OSes. No wonder it was so uncommon.

anyfoo 4y ago
It claims itself as an "embedded" processor, so it likely just wasn't meant to run PC OSes. According to Wikipedia at least, Intel did not even expect the 286 to be used for PCs, but for things such as PBXs. And ARM Cortex M still doesn't have an MMU either, for some applications you can just do without. Especially because both the 286 and this 376 beast did have segmentation, which could subsume some of the need for an MMU (separated address spaces, if you don't need paging and are content with e.g. buddy allocation for dividing available memory among tasks).
- deleted 4y ago
  [deleted]
marssaxman 4y ago
It is very common for embedded systems processors not to have an MMU. If it ran any OS at all it would likely have been some kind of RTOS.
blueflow 4y ago
Using paging/virtual memory is not a requirement for an OS, even when all currently popular OSes make use of it. Intel CPUs before the 80286 did not have an MMU, either.
- anyfoo 4y ago
  Did they even call it an MMU already? The 286 only had segmentation, which arguably is just an addressing mode. It introduced descriptors that had to be resolved, but that happened when selecting the descriptor (i.e. when loading the segment register), where a hidden base, limit, and permission "cache" was updated. Unlike paging, where things are resolved when accessing memory.

kazinator 4y ago

0x80386 - 16 = 0x80376 :)

zymhan 4y ago

Since the page is loading slowly, an archive link: http://web.archive.org/web/20220816012342/https://www.pagetable.com/?p=460 http://web.archive.org/web/20220816012342/https://www.pageta...