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

[John Reagan]

On Monday, March 16, 2015 at 9:51:28 AM UTC-4, Bob Koehler wrote:
> In article <55034b0d$0$24548$c3e8da3$f6268168 at news.astraweb.com>, JF Mezei <jfmezei.spamnot at vaxination.ca> writes:
> > 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.
> 
>    And I've been running a mixture of 32 bit and 64 bit code on my Alpha
>    under VMS for many a years now.  Ony under DEC UNIX did I run in pure
>    64 bit on Alpha.
> 

Tru64 (like -m64 on Linux boxes) forces 64-bit addresses by default (it doesn't map the 32-bit address space to shake out broken code - eventually).

You have to think about data addresses vs code addresses separately.  The data addresses are 'easy'.  It is the code addresses that get you spinning... on Alpha, you have Procedure Descriptors (allocated in 32-bit space so you can reference them with a 32-bit pointer).  Those PDs contain the real 64-bit target address.  On Itanium, you have the short section (allocated in 32-bit address space) pointing to function descriptors (also allocated in 32-bit address space) which contain the real 64-bit target code address (and the GP value).  For the x86 calling standards, representing code addresses that work in a mixed environment will be a little tougher. And bound procedure values always are fun to figure out.