Hacker News Reader

Comment by ack_complete | Hacker News Reader

> I believe that only the first Pentium 3 core, Katmai, did this.

No, all Pentium 3s as well as the Pentium M. Pentium 4 notably didn't suffer from it, but it of course had many, many, MANY other performance issues.

> I have some faint memories of hearing somewhere that Long Mode didn't support x87. I wonder if it is related to this early info you mention and it being Microsoft specific.

It was VM86 mode that Long Mode didn't support, which was one of the rumored reasons for removing 16-bit NTVDM support (among many). x87 and MMX were always supported in long mode and notably some libraries like OpenBLAS still use x87 instructions. Windows does prohibit use of x87/MMX in kernel mode where the need is negligible.

View on HN

>> I believe that only the first Pentium 3 core, Katmai, did this.

> No, all Pentium 3s as well as the Pentium M. Pentium 4 notably didn't suffer from it, but it of course had many, many, MANY other performance issues.

I had to google a bit to confirm this, and seems like I'm not the only one that understood it the way I did:

https://www.vogons.org/viewtopic.php?p=1360606#p1360606

https://www.vogons.org/viewtopic.php?p=1360620#p1360620

Basically, the info I knew was that Katmai had 128 Bits SSE registers but processed it as 2x64 Bits. That info is well reference pretty much everywhere. What is NOT explicitly mentioned is whenever Coppermine/Tualatin maintained that arrangement or had 128 Bits compute units for SSE, so the wording always made Katmai to look like an exception, as if everything else was 128 Bits.

Another fun issue with the split 64/64 support: lo-hi order.

You see, when two orders are possible, of course Intel had to ship both.

Yeeep, P3 vs P4. Which used which, is left as an exercise to you, dear reader.

> which was one of the rumored reasons for removing 16-bit NTVDM support

They already had a 16-bit software emulator for running NTVDM on other archs.

Apparently the real reason was they wanted to drop some software compatibility restrictions, like the small max size of HANDLE tables needed for 16-bit compat.

> but it of course had many, many, MANY other performance issues.

The whole RAMBUS debacle... OTH DDR chipsets for Tualatin had shown what it was the end game for the P6 arch.

Not just the RAMBUS debacle, that 20 stage pipeline and IIRC the barrel shifter wasnt as good as on P3 or AMDs CPUs...

Reply on news.ycombinator.com