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.
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.
> 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.
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.
The whole RAMBUS debacle... OTH DDR chipsets for Tualatin had shown what it was the end game for the P6 arch.
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).
Also, the GF4MX was just a GeForce256 in a trenchcoat, and didn't have vertex shaders (at least exposed to software, the T&L engine was still a vertex shader like engine, only the code was all written by nvidia and loaded from ROM).
GF3 was a very short lived product, even more short lived than GF2MX.
And the crucial thing here is what at the time of GF/GF2 you still could buy a computer without a proper[0] 3D and video output acceleration[1], but by the time of GF4MX (which is GF2MX on the booster shoes and VPE - and only a year and half later at the worst) you have no option not to get a full package.
SIS died, 3Dfx died even earlier, S3 became irrelevant and Intel was for the button pushers till i945 - which came only in 2005.
And while at first the price even for GF4MX420 was ~$100 it did two things:
- pushed the price for GF2MX series well below $50 (and quite soon followed the suit) so anything now had DX7 level 3D on-board
- pushed the price for every other 3D accelerator waaay down
- made MPEG and video acceleration the default in everything
[0] emphasis on the 'proper'
[1] though you needed to get out of the way to do so, eg i815, G450 - but you could!