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

[Stephen Hoffman]

On 2015-03-13 20:39:41 +0000, JF Mezei said:

> On 15-03-13 10:04, lists at openmailbox.org wrote:
> 
>> 64 bit support was and is a disaster. 32 bit and 64 bit code can't coexist.
> 
> If that is the case, how did Apple manage to progressively make OS-X go
> from 32 to 64 bits ?  There was a time where much of the OS was still 32
> bits but allowed apps to be 64 bits and vice versa for more recent times.

The first 64-bit transitional support in OS X was back around 10.3, 
with the PPC gear.

Here is a technical discussion of the 64-bit OS X transition with more 
recent OS X and for x86-64 systems, written for application 
programmers:  
<https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/64bitPorting/intro/intro.html> 


With OS X, applications are either compiled as 32-bit or as 64-bit, and 
AFAIK you can't mix the two within the same application.

This mixing may be what lists is alluding to with the most recent 
claims, but I'd seriously doubt it'd a factor with executing OpenVMS 
code on x86-64.  This as OpenVMS application and system code has been 
running on 64-bit processors for more than twenty years, and also 
because the OpenVMS x86-64 port inherently does not have any existing 
legacy x86-32 32-bit executable user code involved anywhere.  So... 
maybe the old 32-bit modes are interesting to some, but very likely 
moot for OpenVMS.

With recent OS X versions, you cannot load certain 32-bit constructs.  
Specifically, kernel code.  With OS X 10.8, support for these existing 
32-bit kernel pieces was ended; the older pieces cannot be loaded.

This deprecation is entirely analogous to an OpenVMS major release, 
when rebuilding user code linked against the OpenVMS kernel can be 
required.

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.)

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.


-- 
Pure Personal Opinion | HoffmanLabs LLC