I think I'm experiencing Deja Vu... 80376 ???

Itanium's back? 😁

Joseph_Joestar wrote on 2023-05-20, 10:20:

Itanium's back? 😁

I hope Intel hasn't decided to move into necromancy, that corpse has been dead and buried for years now.

Funnily enough I do have an Itanium CPU on my display shelf, cant remember how I got it but it sure does look pretty sitting up there with my other tech tinkets.

This has been coming for a while, the surprising part is that they haven't dropped x87/MMX.

jmarsh wrote on 2023-05-20, 13:24:

This has been coming for a while, the surprising part is that they haven't dropped x87/MMX.

They more or less have dropped x87 and coders/devs are told not to use it for any new applications. MMX is gone entirely from modern hardware, but was folded into AVX, so it can sort of still be used, with code modifications.

RetroGamer4Ever wrote on 2023-05-20, 13:49:

They more or less have dropped x87 and coders/devs are told not to use it for any new applications. MMX is gone entirely from modern hardware, but was folded into AVX, so it can sort of still be used, with code modifications.

It's not gone at all. MMX registers still share the same space as the 80-bit x87 registers and have nothing at all to do with AVX - it is possible to mix AVX and x87/MMX code without any restrictions.

The FPU state is still preserved across threads/tasks in the current windows 11 kernel and this white paper that Intel just released explicitly says the TS bit in CR0 is still usable (for lazy context saving).

VirtualBox actually is trying to bring back binary translation (to run under Apple Silicon). But yes, this is a pretty big deathblow to 16-bit virtualization (and native running...). And likely 32-bit OSes too.

I don't understand why Intel would do this -- the power/performance improvement is likely negligible, albeit there may be some lower testing cost.
However doing this just reminds people that Intel can kill x86 compatibility at any moment, and may make people start thinking about emulation, having software that is less tied to x86, moving to ARM, RISC-V, etc. Just look at the comments of the above articles, which come from people who likely have 0 interest in 16-bit x86, but just see this as the writing on the wall for 32-bit x86.
I see that as much worse for Intel that whatever little they gain by removing any type of "legacy" support.

Yeah, it's probably not a coincidence that the touted lists of 'benefits' are all benefits for Intel, but make absolutely no difference to the end user. True, a modern 64-bit Intel CPU starts up in real mode. Does that make the slightest bit of practical difference to anyone, besides the fact that it sounds vaguely 'silly' to the average layman?

It'd be nice to know what *actual* improvements people should expect from this (if any), beyond some knee-jerk notion of "removing all this old shit must make it better!". Haven't gone through that entire PDF, but when I hit Ctrl+F and look up 'benefit', 'performance', 'improvement', 'speed', 'fast', nothing turns up.

For instance, I'm aware that one of ARM's major performance edges over x86 is much simpler instruction decoding. But that sort of thing won't be fixed by the proposed update. What will?

"Using the simplified segmentation model of 64-bit for segmentation support for 32-bit applications, matching what modern operating systems already use."

I wonder if this means under this architecture, 32-bit programs on Windows x64 will be able to access as much memory as 64-bit ones, rather than being capped at ~2GB? If so, it may be helpful in use cases where 32-bit is needed, like having to make use of third-party DLLs that only comes in 32-bit form.

Other than that I don't think there are any apparent benefit. The BIOS in its entirety may need to be rewritten for the new boot sequence that no longer involves any 16/32-bit states, though I'm not sure if this will involve changes to UEFI bootloaders/kernels as well...

But still... looks like VM solutions will have to do more work than before.

LSS10999 wrote on 2023-05-21, 14:00:

"Using the simplified segmentation model of 64-bit for segmentation support for 32-bit applications, matching what modern operating systems already use."

I wonder if this means under this architecture, 32-bit programs on Windows x64 will be able to access as much memory as 64-bit ones, rather than being capped at ~2GB? If so, it may be helpful in use cases where 32-bit is needed, like having to make use of third-party DLLs that only comes in 32-bit form.

I don't think that makes sense as if you were to want to access memory using long long pointers, then you'd want to recompile to full 64-bit anyway. There is the ability though, to use 32-bit pointers, and a full mix of 32-bit and 64-bit instructions (again, a recompile, but I guess a partial porting that might be beneficial and easier?):
https://en.wikipedia.org/wiki/X32_ABI

I think if 32-bit protected mode goes away, 32-bit applications could evolve to be more like x32 abi that was proposed. Maybe. I don't know any other reason to keep it.

64-bit operating systems will still run 32-bit apps exactly as they already do, there aren't any changes to that.

I'm worried about WINE support on Linux.
Linux kernal used to keep 16-Bit/286 Protected Mode support for Windows 3.x applications. Not sure about the recent status, though.

https://news.softpedia.com/news/Linux-Kernel- … ns-447273.shtml

But to be honest, an x86 emulation based on DOSBox would probably do for most casual users.

It's the professionals with real, advanced 16-Bit Windows applications who suffer.
Like AutoSketch 1.x or one of the old 3D modeling programs.

Such programs do still benefit from raw CPU power.
Limiting them to 486 performance levels isn't exactly a nice out sight.

Despite being from the early 90s, they could still work with large data sets and 4k/8k screen resolutions.

But on the other hand, which professional does use Linux? 🙂

the3dfxdude wrote on 2023-05-21, 14:13:

I don't think that makes sense as if you were to want to access memory using long long pointers, then you'd want to recompile to full 64-bit anyway. There is the ability though, to use 32-bit pointers, and a full mix of 32-bit and 64-bit instructions (again, a recompile, but I guess a partial porting that might be beneficial and easier?):
https://en.wikipedia.org/wiki/X32_ABI

I think if 32-bit protected mode goes away, 32-bit applications could evolve to be more like x32 abi that was proposed. Maybe. I don't know any other reason to keep it.

Back then I had situations requiring some Java code be run with a 32-bit JVM because the project needs to interact with some third-party 32-bit DLLs (which cannot be done with a 64-bit JVM).

As the project may require a lot of RAM I need to specify the amount of memory it's allowed to use via -Xmx parameter. With 64-bit JVM I can specify as much as I deem necessary so long as the system has enough memory, but with 32-bit JVM the maximum I could specify was about 1.2GB and was rather delicate that it would terminate after running for a while and could not be restarted with the same setting anymore. Windows can no longer allocate that much -Xmx to the 32-bit JVM from this point on, even though the system still has an adequate amount of RAM available. Around 1GB was the safe spot for such a use case, though it was barely enough.

So far this is the only case where I ran into the memory limitations for individual 32-bit processes. I haven't tried enabling 4GT yet, though I'm not sure whether 4GT is useful on 64-bit Windows for such scenarios...

Jo22 wrote on 2023-05-21, 14:33:

I'm worried about WINE support on Linux.
Linux kernal used to keep 16-Bit/286 Protected Mode support for Windows 3.x applications. Not sure about the recent status, though.

https://news.softpedia.com/news/Linux-Kernel- … ns-447273.shtml

Wine already uses usermode emulation for x86 to run on Apple M1, I believe. So they will probably just do that for all win32 on all platforms. win16 probably will also work the same in Wine, but the future doesn't look that bright for compatibility. There will be alot of work for people like us having new systems fixing stuff all over again. Now I think the intention of the proposal here would still allow something like Wine to run natively, but I am not sure, and I'm not that trusting. Why propose dropping x86 32-bit from being able to boot into, if it really doesn't impact anything at all? I do agree this likely will have a larger impact on a number of applications. Applications likely will break. Maybe they're just getting reading for a completely locked down Windows 12?

LSS10999 wrote on 2023-05-21, 14:58:

Back then I had situations requiring some Java code be run with a 32-bit JVM because the project needs to interact with some thi […]
Show full quote

the3dfxdude wrote on 2023-05-21, 14:13:

I don't think that makes sense as if you were to want to access memory using long long pointers, then you'd want to recompile to full 64-bit anyway. There is the ability though, to use 32-bit pointers, and a full mix of 32-bit and 64-bit instructions (again, a recompile, but I guess a partial porting that might be beneficial and easier?):
https://en.wikipedia.org/wiki/X32_ABI

I think if 32-bit protected mode goes away, 32-bit applications could evolve to be more like x32 abi that was proposed. Maybe. I don't know any other reason to keep it.

Back then I had situations requiring some Java code be run with a 32-bit JVM because the project needs to interact with some third-party 32-bit DLLs (which cannot be done with a 64-bit JVM).

As the project may require a lot of RAM I need to specify the amount of memory it's allowed to use via -Xmx parameter. With 64-bit JVM I can specify as much as I deem necessary so long as the system has enough memory, but with 32-bit JVM the maximum I could specify was about 1.2GB and was rather delicate that it would terminate after running for a while and could not be restarted with the same setting anymore. Windows can no longer allocate that much -Xmx to the 32-bit JVM from this point on, even though the system still has an adequate amount of RAM available. Around 1GB was the safe spot for such a use case, though it was barely enough.

So far this is the only case where I ran into the memory limitations for individual 32-bit processes. I haven't tried enabling 4GT yet, though I'm not sure whether 4GT is useful on 64-bit Windows for such scenarios...

I'm not as familiar with the full capabilities of JVM in 32-bit, but as you said there does seem to be a delicate limit in my experience too. But I don't see this as fixing that problem, and I don't see general applications able to suddenly access more memory. Unless they somehow fix PAE to be as performant up to 64GB as long mode, but if anything, I still think they are likely to break that too, as there isn't much reason to have that around. I would guess that the suggested 32-bit compatibility is for continuing to support things like Wine or Win32 in a 64-bit OS more than actually making anything better, until all that gets forgotten. But I think there will still be a few apps that break if they go forward with whatever is actually removed. The older, the more likely it will, I would guess.

the3dfxdude wrote on 2023-05-21, 15:13:

Jo22 wrote on 2023-05-21, 14:33:

I'm worried about WINE support on Linux.
Linux kernal used to keep 16-Bit/286 Protected Mode support for Windows 3.x applications. Not sure about the recent status, though.

https://news.softpedia.com/news/Linux-Kernel- … ns-447273.shtml

Wine already uses usermode emulation for x86 to run on Apple M1, I believe. So they will probably just do that for all win32 on all platforms. win16 probably will also work the same in Wine, but the future doesn't look that bright for compatibility. There will be alot of work for people like us having new systems fixing stuff all over again. Now I think the intention of the proposal here would still allow something like Wine to run natively, but I am not sure, and I'm not that trusting. Why propose dropping x86 32-bit from being able to boot into, if it really doesn't impact anything at all? I do agree this likely will have a larger impact on a number of applications. Applications likely will break. Maybe they're just getting reading for a completely locked down Windows 12?

Not to mention that WINE somehow manages to run 32bit apps on 64bit only macOS machines as well.

I don't follow macOS much except to boot it in a VM (shock gasp!) to download the macOS equivalent for Steam games so can't provide much detail except for the following.

https://www.codeweavers.com/blog/jwhite/2019/ … of-crossover-19
https://www.codeweavers.com/support/forums/ge … 1836;msg=251836
https://www.codeweavers.com/support/forums/ge … eral/?t=27;msg=

None of this relates to Intel and AMD though since the CPU will still support 32bit code except for where it doesn't as mentioned in the pdf.

I'm suprised they don't lock it behind Intel On-Demand first and see who buys it heh.
https://www.intel.com/content/www/us/en/produ … d/overview.html

the3dfxdude wrote on 2023-05-21, 15:13:

Maybe they're just getting reading for a completely locked down Windows 12?

Win11 already required TPM2.0, and provided the ability for software to check TPM as well as Secure Boot status (demonstrated by Valorant).

Maybe with Win12 there will be more restrictions and more features for software to check if the system is locked down or not.

Considering they're working on WSA (to run Android stuffs), these features might also be exposed there to provide a SafetyNet-like attestation for apps that want such information.

Per Microsoft's "Windows Hardware Certification Requirements", M$ said this regarding Secure Boot:

"MANDATORY: Enable/Disable Secure Boot. On non-ARM systems, it is required to implement the ability to disable Secure Boot via firmware setup. A physically present user must be allowed to disable Secure Boot via firmware setup without possession of Pkpriv. Programmatic disabling of Secure Boot either during Boot Services or after exiting EFI Boot Services MUST NOT be possible. Disabling Secure MUST NOT be possible on ARM systems."

This was for Windows 8 when it was first introduced, and as of Windows 11 Secure Boot is still not mandatory for non-ARM installation (only TPM2.0, which is not covered here).

So users are not completely locked down and can still choose to disable Secure Boot to install another non-Microsoft OS, even with this new x86S architecture, unless M$ finally decided to amend the certification requirement to remove this mandatory line.

Well it's kind of like the ISA slot. They first made it "optional", and things like -5V not needed anymore. One by one the manufacturers decide to pull it out, and change chip sets breaking compatibility (you have no slot, so it doesn't need to work like a full ISA bus). Now about 2020 on, ISA bus signaling is getting removed completely that even integrated legacy stuff is long gone. They deleted that line like about -5V like it never existed in the ATX spec. 16/32-bit is kind of coming to that point, now it will be impossible to support a large portion of the PC's existence. In terms of secure boot being optional, again, that is just a recommendation by Microsoft. All that has to happen is the manufacturers start one by one locking down their products. Even if it is an option, eventually you have no option, and they'll delete that line too, like it never happened. So I probably shouldn't say that Win12 will for sure being the deciding factor, but I'm telling you, many things are starting to line up that the x86 platform is going to soon be radically different. I wonder who will pull the trigger, but it will be very subtle.