[Info-vax] VAX vs. MV/8000 [was Re: Hard links on VMS ODS5 disks]

[John Reagan]

On Monday, August 28, 2023 at 12:26:04 PM UTC-4, John Dallman wrote:
> In article <uci441$lgj$2... at news.misty.com>, b... at softjar.se (Johnny
> Billquist) wrote: 
> 
> > I've tried to stay out, and don't want to get too deep in. 
> > But in a sense, my question/issue would be: Can you take a binary 
> > for x86 and run it without any "mode bit", or anything else, on an 
> > x86-64 and it works?
> Depends on how much setup you're willing to do before kicking off the 
> binary. As Dan says, if you set up the segments right, many of the 
> instructions will execute, but you'll hit problems with others, and 
> certainly when you start trying to call OS functions that are at all 
> complicated.
> > Individual instructions is not all. Will the stack offsets remain 
> > the same when I push stuff, will address references be fine when I 
> > just use 32 bits, and do arithmetic and address offsets and so on.
> Stack offsets and arithmetic operations will likely be OK; there may be 
> some corner cases. The problem comes with memory references being passed 
> between 32-bit and 64-bit code. Those are offsets within segments, and 
> there is no intrinsic or canonical mapping between 32-bit segments and 
> 64-bit segments on x86. 
> 
> To run executables intended for a 32-bit OS on a 64-bit OS, the usual 
> route on x86 is "thunks", small chunks of code that receive OS calls made 
> by the 32-bit code map the data into 64-bit addressing, and then call the 
> OS' native 64-bit API. That's how 64-bit Windows and Linux run 32-bit 
> executable. 64-bit macOS did that too, until Apple removed its ability to 
> run 32-bit executables. The thunks are collected into special versions of 
> the various run-time libraries that 32-bit code calls. Sometimes, for 
> performance reasons, chunks of the "real" 32-bit run0time libraries are 
> included.
> > If that is the case, then yes, it has been done the same way DG did 
> > it. Which truly meant you could take your old binaries and run them 
> > on the newer hardware without any added trickery.
> No, it isn't the full DG job. But it isn't a VAX-style separate mode 
> either. It's something in between. 
> 
> An example of a modern separate mode comes with ARM. The ARM32 and ARM64 
> instruction sets are /very/ different. Most ARM32 instructions are 
> conditionally executed using predicate flags in the instructions, taking 
> up 5 bits in almost all instructions. ARM64 threw that out, and some old 
> ARM hands reckon ARM64 is more like MIPS than ARM32. 
> 
> John
I've tried to stay out of this so far, but I do want to point out that 64-bit mode
doesn't use CS, DS, ES,  SS segments in that way.  You can put whatever values you want into
them, but they read as 0.  We do use GS for some things in the OS.

>From the architecture manual, Volume 1,
section 3.4.2.1, "Segment Registers in 64-Bit Mode"

In 64-bit mode: CS, DS, ES, SS are treated as if each segment base is 0, regardless of the value of the associated
segment descriptor base. This creates a flat address space for code, data, and stack. FS and GS are exceptions.
Both segment registers may be used as additional base registers in linear address calculations (in the addressing
of local data and certain operating system data structures).

Even though segmentation is generally disabled, segment register loads may cause the processor to perform
segment access assists. During these activities, enabled processors will still perform most of the legacy checks on
loaded values (even if the checks are not applicable in 64-bit mode). Such checks are needed because a segment
register loaded in 64-bit mode may be used by an application running in compatibility mode.

Limit checks for CS, DS, ES, SS, FS, and GS are disabled in 64-bit mode.