Wednesday, September 25th 2024

Intel Updates 64-Bit Only "X86S" Instruction Set Architecture Specification to Version 1.2

Intel has released version 1.2 of its X86S architecture specification. The X86S project, first announced last year, aims to modernize the x86 architecture that has been the heart of PCs since the late 1970s. Over the decades, Intel and AMD have continually expanded x86's capabilities, resulting in a complex instruction set that Intel now sees as partially outdated. The latest specification primarily focuses on removing legacy features, particularly 16-bit and 32-bit support. This radical departure from x86's long-standing commitment to backward compatibility aligns with the simplification of x86. While the specification does mention a "32-bit compatibility mode," we are yet to how would 32-bit apps run. This ambiguity raises questions about how X86S might handle existing 32-bit applications, which, despite declining relevance, still play a role in many computing environments.

The potential transition to X86S comes at a time when the industry is already moving away from 32-bit support. However, the proposed changes are subject to controversy. The x86 architecture's strength has long been its extensive legacy support, allowing older software to run on modern hardware. A move to X86S could disrupt this ecosystem, particularly for users relying on older applications. Furthermore, introducing X86S raises questions about the future relationship between Intel and AMD, the two primary x86 CPU designers. While Intel leads the initiative, AMD's role in the potential transition remains uncertain, given its significant contributions to the current x86-64 standard.
Sources: InstLatX64, via Tom's Hardware
Add your own comment

32 Comments on Intel Updates 64-Bit Only "X86S" Instruction Set Architecture Specification to Version 1.2

#26
tfp
In one hand x86 is "so crappy and power intensive" because it has all this old ISA that must be support but isn't used often so it should be cleaned up.
In the other hand "OMG how will I run my 20+ year old DOS games that need 16bit support and COBOL programs?!?!?. They both need the latest HOTNESS"

If AMD came up with this I think there would be less complaints, or maybe just complaints by different people.
Posted on Reply
#27
ScaLibBDP
Wirko16-bit programs run in 32-bit Windows, at least in 7.
Edit: they run in 32-bit Windows 10 too. Apparently you need to enable NTVDM.
Corrected my initial post and explicitly specified that 16-bit software support disabled by Microsoft on 64-bit versions of Windows ( possibly around 2007 year ).
Wirko16-bit programs run in 32-bit Windows, at least in 7.
Edit: they run in 32-bit Windows 10 too. Apparently you need to enable NTVDM.
>>...Apparently you need to enable NTVDM...

No.

16-bit software support is disabled on 64-bit WIndows completely.
ScaLibBDPCorrected my initial post and explicitly specified that 16-bit software support disabled by Microsoft on 64-bit versions of Windows ( possibly around 2007 year ).



>>...Apparently you need to enable NTVDM...

No.

16-bit software support is disabled on 64-bit WIndows completely.
Here is a link to look at for more details:

learn.microsoft.com/en-us/windows/compatibility/ntvdm-and-16-bit-app-support
Posted on Reply
#28
OSdevr
igormpThat also has nothing to do with the ISA, but rather software (again) and bus limitations. I'm not sure if it's possible to do P2P transfers with Sata, but with NVMes you can use PCIe P2P (and not only NVMes) without going through RAM at all. It works in exact the same way in both ARM and x86.
AHCI (aka SATA) and later generation ATA (aka IDE) use PCI busmastering DMA which I believe allows device to device transfers, it's just a good idea to buffer to RAM. Ancient ISA DMA couldn't but that was cursed by an angry god and you often didn't want to use it anyway. D2D works fine on NVMe's provided they have DRAM caches because they're buffering with their on board RAM more effectively than the CPU ever could with system RAM.
ScaLibBDP>>...The x86 architecture's strength has long been its extensive legacy support,
>>...allowing older software to run on modern hardware.

I didn't use Microsoft Windows Vista and Windows 8.x 64-bit OSs at all but I know that 16-bit software support is Not available in Windows 7, Windows 10 and Windows 11 64-bit OSs.

For example, this is an error message if you try to execute a legacy 16-bit Turbo C++ compiler version 3.0 on Windows 7 64-bit :
...
This version of C:\WorkLib\TC30\Bin\TCC.EXE is not compatible with the version of Windows you're running.
Check your computer's system information to see whether you need a x86 (32-bit) or x64 (64-bit) version of
the program, and then contact the software publisher.

...

So, in reality Microsoft disabled 16-bit software support on 64-bit OSs a long time ago ( possibly around 2007 year ).
This was really decided by AMD not Microsoft. The long and short of it (you could read for hours about this and related stuff) is that a 32-bit x86 processor running in 32-bit Protected Mode (as in a 32-bit OS) can be easily switched into a 16-bit Virtual 8086 Mode to run a 16-bit program. However when AMD introduced x64 (as 64-bit "Long Mode"), while they gave a similar Compatability Mode for running 32-bit programs to switch to, they did not allow you to switch to Virtual 8086 Mode from Long Mode (I remembered things incorrectly earlier). I don't know why AMD decided to do this, especially since you can switch to v8086 from Protected Mode, but for whatever reason they decided you can't go from 64-bit to 16-bit.
Posted on Reply
#29
Nhonho
OSdevrThis has nothing to do with unifying CPU and GPU memory nor would that be a very good idea. CPU memory prefers lower latency while GPU memory prefers high bandwidth. It's not a hard rule (consoles do it) but it gives best performance overall. What's more GPU memory moves data so fast that connectors ruin data integrity so there's no way to make it upgradable or replaceable without soldering. This is starting to become a problem for CPU memory too and is why laptops with soldered RAM tend to have higher RAM speeds than when they're on SODIMMs.

As for copying HDDs, buffering to RAM is pretty much required even today. When one device has data, the other often isn't immediately able to receive it. This is especially true with HDDs due to files being in different places and split up into different fragments on disk. I don't know if this is still true but it used to be faster to read and write data near the edge of a disk than the center because the tracks near the edge are moving faster.
Another keyboard engineer... :rolleyes:
Posted on Reply
#30
OSdevr
NhonhoAnother keyboard engineer... :rolleyes:
Probably should have replied to my most recent comment if you wanted to give me that title. I like low level stuff.
Posted on Reply
#31
Wirko
ScaLibBDPCorrected my initial post and explicitly specified that 16-bit software support disabled by Microsoft on 64-bit versions of Windows ( possibly around 2007 year ).
ScaLibBDP16-bit software support is disabled on 64-bit WIndows completely.
It's not about disabling, it's just that MS never made the appropriate NTVDM. NTVDM is a compatibility layer, or some sort of VM ... I may use wrong terms, my understanding is not very good here. But it's not an emulator.

Not even 64-bit XP and Server 2003 had the ability to run 16-bit programs:
support.microsoft.com/en-us/topic/54322ff9-0d07-0032-e02c-8f67e34e5cb7

But, just as a proof of concept, some hacker put the right pieces together in the right order and it worked. Here's the NTVDMx64 project, with a lengthy explanation.
github.com/leecher1337/ntvdmx64
OSdevrthey did not allow you to switch to Virtual 8086 Mode from Long Mode
Maybe it's possible as a two-step transition in a VM inside another VM (NTVDM inside WOW64). That's how I understand the operation of the NTVDMx64.
Posted on Reply
#32
Robin Seina
ScaLibBDPSo, in reality Microsoft disabled 16-bit software support on 64-bit OSs a long time ago ( possibly around 2007 year ).
MS disabled the 16-bit software support with end of WinME, Win2k/XP have it already disabled.
Posted on Reply
Add your own comment
Nov 21st, 2024 13:54 EST change timezone

New Forum Posts

Popular Reviews

Controversial News Posts