Hacker News Reader

Comment by zir_blazer | Hacker News Reader

> Additionally, some CPUs at the time only had a 64-bit data path and had to split SSE2 ops, but because of their 4-1-1 decode template, could only decode one such instruction per cycle.

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

> This caused some confusion with the 64-bit version of Windows since Microsoft tried to say that x87/MMX shouldn't be used in long mode, but after queries from video processing companies had to document that the x87/MMX registers were enabled and context switched for user mode code.

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.

View on HN

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

No, the Pentium M (Banias / Dothan) also needed multiple cycles for basic SSE2 ops (with a few exceptions like PUNPCKLQDQ or PMOVMSKB), a full four years after Katmai (source: I owned one, and wrote SIMD on it for codec libraries).

> 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.

> 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...

> 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.

>> 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.

Reply on news.ycombinator.com