[Info-vax] OT: news from the trenches (re: Solaris)

[John Reagan]

On Friday, March 13, 2015 at 5:32:24 PM UTC-4, Stephen Hoffman wrote:

> 
> As for 32-bit source code -- as distinguished from the 32-bit run-time 
> environment -- VSI will have to figure out if they can continue to do 
> what OpenVMS on Alpha and Itanium did, and sign-extend the legacy 
> 32-bit code out into 64-bit at run-time.    I expect that'll be pretty 
> obvious.   Whether VSI might then decide to reverse the current source 
> code practices and work toward uncluttered and native 64-bit support at 
> the source-code level and to particularly make the support for the old 
> 32-bit source code constructs into the cluttered within the source code 
> and build procedures and otherwise delimit the old code within pragmas 
> or non-default compiler switches, now that is a separate question.   
> (I'd expect the former here, but would hope for the latter.  Look 
> forward.  Not backward.  But I digress.)

Just as soon as 64-bit descriptors become the default, all the code that handles descriptors today gets updated, all the languages do 64-bit pointers, etc.  Makes the whole 'recompile and go' rather nasty especially in a mixed-architecture cluster.

> 
> Outside of whatever mode the x86-64 chip powers up into, I wouldn't 
> expect VSI to particularly look at implementing the older 32-bit or 
> 16-bit x86 operating modes during their port -- and VSI will probably 
> just sign-extend existing 32-bit code to 64-bit, like OpenVMS does now 
> -- but that's fodder for another day.
> 

gack, spit, cough, ugh...  I can promise we will not run on a chip in any of those old modes.  REAL mode with 1MB of memory address space? You would need at least PROTECTED mode, but I digress.  

Actually, for those of you keeping score at home, something will execute in REAL mode for a quick moment as the chips come up in REAL mode after a reset.  No different to Alpha or Itanium where the OS has to work with physical addresses prior to enabling virtual memory.