[Info-vax] Compatibility and 64-bit

[Stephen Hoffman]

On 2015-03-15 21:53:56 +0000, JF Mezei said:

> On 15-03-15 14:18, Stephen Hoffman wrote:
> 
>> So long as you're only working within your own code, sure.  Works  
>> great.  Have at.
> 
> Thanks, hadn't considered that.
> 
> So in C, how can I define a pointer to be 32 bit or 64 bits ? Aren't 
> all pointers sizes defined by the compiler at compile time ?

Everything is defined at compile time, certainly.  On OpenVMS Alpha, 
all virtual addresses are 64 bits, and always have been.  That means 
that pointers are either 64-bit addresses, or they are 32-bit addresses 
that get sign-extended to 64-bit addresses.  BTW, check the pragmas at 
<http://labs.hoffmanlabs.com/node/1771>.  There are other related 
mechanisms, and which are discussed in the 64-bit guide I referenced 
earlier.

> I must have been asleep for a long time. I take it that C programs on 
> Alpha 8.3 use 32 bit pointers and apps run in 32bit mode and all the 
> normal systen calls made expect 32 biut pointers even if the system 
> itself runs in 64 bits ?

OpenVMS Alpha V7.0 and later added support for filling out the 64-bit 
virtual address space, though earlier versions did always used 64-bit 
addresses.   That means V7.0 and later allowed access to the 64-bit 
virtual address space "hole" that had previously between located 
between the P0 and P1 process space, and the S0 and S1 system space.  
What was known as P2 and S2 space.  Prior to V7.0, the P2 and S2 
virtual addressing "hole" was reserved for future use and effectively 
didn't exist; there was no virtual memory page table support that 
allowed any access into that region of virtual address space.

On OpenVMS Alpha, C pointers are 32-bit or 64-bit based on the compiler 
settings the object was compiled with, or the pragmas.

OpenVMS Alpha 32-bit pointers can be stored in a longword, but still 
get sign-extended at run-time.

OpenVMS Alpha 64-bit pointers do not need sign extension.

> So it would be only special applications that are compiled in true 64 
> bit mode and they have to use different descriptor structures so that 
> the system services map the argument to a different structure 
> definition with bigger pointer ?

"True 64 bit mode"?  Is there a false 64-bit mode?  Donno.  But 
seriously, it's quite common to see 64-bit objects making 64-bit calls 
using 64-bit pointers and 64-bit system services from within an OpenVMS 
Alpha executable image, yes.   But 32-bit stuff can be mixed into the 
executable and there can be calls between 32- and 64-bit code,  Do 
definitely read the 64-bit guide I referenced, see the descriptor 
formats, and have a look at $DESCRIPTOR64( YourSymbolName, "Your 
String") and other such, and go experiment.

Or if you're over on OS X, this stuff is largely handled for you by the 
C compiler and the run-time, and given that most stuff is 64-bit now, 
the discussion is largely moot.

Some OpenVMS Virtual-Addressing-Related Topics:
<http://labs.hoffmanlabs.com/node/228>
<http://labs.hoffmanlabs.com/node/1771>
<http://labs.hoffmanlabs.com/node/1005>

> But going to x86 where everything will be compiled 64 bits including OS 
> system calls, won't that problem go away since both user programs and 
> system services will expect 64 bit pointers for everything ?

What x86-64 virtual addressing looks and works like, and what the 
requirements and the restrictions might be, we shall eventually learn 
more about as the OpenVMS port and the V9.0 release gets closer to 
availability.  While I'd expect to see the current 32-bit and 64-bit 
model carry through, it's not certain what VSI might implement.  This 
presuming VSI does follow through with the roadmap, of course.

>> Though the sizeof also changes across one of these 32-to-64-bit  
>> migrations, but there are cases where compatibility is necessary across 
>>  versions for data structures stored in files or network packets.
> 
> But in the specific case of pointers, those would never be stored in a 
> file right ?

Never?  That's your call.  It's rare.  But I've had cases where process 
virtual addresses in files.  It's far more common to have derivatives 
such as size fields and base-offset fields — fields which can also end 
up increasing in allocated size when you move to 64-bit addressing — 
stored within files and messages.  You can also hit cases where your 
longword pointers can no longer "reach" where your data happens to be 
mapped when 64-bit addressing is being used, which means those pointers 
and any associated pointer math and pointer range checks and length 
values and base-relative values can need to be promoted to quadwords.  
See the 64-bit descriptors for related information.

> 
>> For the modern OpenVMS time storage, proper "binary" storage is twenty  
>> bytes IIRC, and not a quadword.
> 
> OK, I am way behind then.

You'll want to read about the UTC system services in the system service 
manuals.  Or if you're on OS X, the C UTC calls will work fine.

> so SYS$BINTIM now returns 20 bytes instead of 8 ?

Nope.  $bintim still returns a quadword.

> When did that change ?

$bintim?  The quadword time value is still eight bytes, though support 
for 64-bit addresses in services including $bintim and $gettim was 
added at V7.0.   UTC support was added into OpenVMS back around V6.2, 
IIRC.

Seriously: go read that 64-bit manual.

If you want to see how some other systems deal with this stuff, see
<http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory/>
<http://duartes.org/gustavo/blog/post/how-the-kernel-manages-your-memory/>




-- 
Pure Personal Opinion | HoffmanLabs LLC