Re: x86S Specification

On 10/22/2024 12:38 PM, Scott Lurndal wrote:

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

John Levine <johnl@taugh.com> writes:

Think about the way that current Intel chips have a native 64 bit architecture
but can still have a 32 bit user mode that can run existing 32 bit application
binaries. So how about if the next generation is native x86S, but can also run
existing 64 bit binaries, even if not as fast as native x86S. They get the usual
cloud operating systems ported to x86S while leaving a path for people to migrate
their existing applications gradually.

>
Several things in this paragraph makes no sense.
>
In particular, x86S is a proposal for a reduced version of the stuff
that current Intel and AMD CPUs support: There is full 64-bit support,
and 32-bit user-level support.  x86S eliminates a part of the
compatibility path from systems of yesteryear, but not that many
people use these parts nowadays anyway.  It's unclear to me what
benefits these changes are supposed to buy (unlike the elimination of
A32/T32 from some ARM chips, which obviously eliminates the whole
A32/T32 decoding path).  It seems to me that most of the complexity of
current CPUs would still be there.

 Most of the proposed changes are unintersting to user mode developers.
 

Yes, on current platforms, they are unlikely to notice.
Would make the chip essentially "useless" for a retro system, but most of these guys are either using vintage parts, or emulation.
Like, little point in trying to run Win98 on a newest-generation platform (and, apparently, getting Win98 working natively on anything much newer than the mid 2000s is pain, as even if the CPU is backwards compatible, most of the other hardware is not).
Then, there is the pros/cons option of "Well, run QEMU or similar..."
Decided to leave out going into thoughts on the QEMU experience (technically works OK, but in some areas is a little lacking).
Though, there is a possible merit to trying to have a userland-only emulator. Unlike full system/OS level emulator, all of the wonk and issues with emulating hardware interfaces and drivers, and with filesystem integration, can largely go away (one can essentially trap out of the emulation at the system-call level).
Though, it is possible more effort than in may seem to try to write usable mockups for KERNEL32.DLL and USER32.DLL and similar (and can't directly copy-paste these parts from Wine; didn't get very far). I think I got annoyed and gave up trying to debug it at the time.
Though, ironically, some code from this past project was copy-pasted into what later became TestKern.
IIRC, the goal at the time was to make something like Wine that ran on a RasPi. Since then, Wine itself has gained this capability (by internally offloading the emulation parts to QEMU). Not looked too much into how this setup works.
But, in any case, at least on theory, the need to stick with x86 as the native ISA for sake of backwards compatibility seems to be weakening.
Had on/off considered trying to revive the idea in a different form, but had mostly stalled out (if the host is 50MHz, running x86 via an interpreter is going to be too slow to be worthwhile).
It seemed likely more practical to try to get RV64G Linux-ELF binaries working than to try to try to get Win32 binaries working. Though, this had also stalled, as now there is the issue of trying to figure out why "ld-linux.so" and similar keep exploding (thus far, all the "actually usable" RV64 builds have been using my own C library).
...

They're definitly interesting to system software (UEFI, Hypervisor,
Kernel folks), if only to clean up the boot and startup paths.
 Those changes also will reduce the RTL verification load, and
perhaps simplify other areas of the implementation leading to further
efficiencies down the road.  The A20 gate should be relegated
to the trash heap of history.

Possibly true, but presumably RTL verification of legacy features is not a contiguous recurring cost...