Hacker News Reader

Comment by Animats | Hacker News Reader

AMD got rid of much of the older baggage when they designed 64-bit mode. There's a 32-bit segmented mode with call gates and rings nobody uses. That was dropped for 64-bit mode, but it's still there in 32 bit mode in shipping processors.

Intel has been burned in the past, though. The Pentium Pro (1995), the first good superscalar microprocessor, was a 32-bit machine that could also run 16-bit code. Intel thought 16-bit was on the way out, so the 16-bit hardware was not fast. Unfortunately for Intel, Microsoft Windows users were still running too much 16-bit code. It ran Windows NT fine; Windows 95, not so much. As a result, the Pentium Pro did not sell well. Intel had to come out with the Pentium II (1997), which was similar to the Pentium Pro but had better 16-bit performance.

View on HN

> Unfortunately for Intel, Microsoft Windows users were still running too much 16-bit code.

The proposal [0] still keeps support for 32-bit user space – or at least as much of it as is commonly used by mainstream operating systems (Windows and Linux). In this case, they are removing obscure features which aren't used by current versions of mainstream operating systems, so the only real impact is going to be (1) people running non-mainstream operating systems, (2) people virtualising legacy versions of mainstream operating systems, (3) apps that try to directly access IO ports from user space – which is a supported feature (albeit very rarely used) on Linux, not officially supported by Microsoft on Windows (although third party kernel drivers have been used to implement it)

Virtualisation of legacy/non-mainstream OSes which use these features will be possible through software emulation, although obviously that has a performance cost.

I wonder what the impact will be on OpenVMS for x86-64?

Is Intel going to drop these legacy features across their entire product line? Or maybe their low-end SKUs will drop them, but they'll keep some high-end SKU which retains them? Although one wonders how long that will last.

[0] https://cdrdv2.intel.com/v1/dl/getContent/776648

>AMD got rid of much of the older baggage when they designed 64-bit mode

Depends on whether you view MMX, and SSE as baggage. They were OK at the time, but I guess we could do a lot better today.

Having said that I still wish they open up X86s. Or may be an even new 86 breaks most of the backward compatibility ( pure 64 bit mode ) but freely open to implement. Meaning if you want backward compatibility you will need to pay AMD or Intel for it.

> The Pentium Pro (1995), the first good superscalar microprocessor …

I thought the i960CA was good.

PPro ran Windows 95 fine, just not at a favorable price/performance point. PPro sold fine for what it was: the very high end, highest price of the Intel line.

I may be remembering things wrong but I thought the reason the Pentium Pro didn't sell very well was its price rather than its performance.

It's performance advantage was only on 32bit code, 16bit code was not further optimized. The high cost (and high manufacturing cost) certainly didn't help either.

That "older baggage" takes up less than 5% of the chip. While I'm all for simplifying the platform, lets not act like it's a major step. It's not going to make much difference either size or speed wise, but it's just plain time to put 32 bit to rest.

> It's not going to make much difference either size or speed wise ...

Wouldn't that depend on what they do with resulting available space?

If that 5% all became dedicated L1 cache instead, that sounds like it'd have a speed impact. :)

There are other costs than silicon real estate. Those modes and microcode need to be validated, tested and add bloat to the boot software stack.

> Those modes and microcode need to be validated, tested and add bloat to the boot software stack.

Just allowing booting directly in 64-bit mode and making 64-bit SMM mode would be enough to avoid boot software stack problems. Riddance of "legacy mode" doesn't require all it.

Reply on news.ycombinator.com