[Info-vax] 64 bit DCL ?

[Keith Cayemberg]

On Friday, January 16, 2015 at 2:22:42 PM UTC+1, VAXman- wrote:
> In article <54b82f3b$0$19803$c3e8da3$33881b6a at news.astraweb.com>, JF Mezei <jfmezei.spamnot at vaxination.ca> writes:
> >Just wondering out-bit  (instead of out-loud :-)
> >
> >If DCL integer values were suddently moved to 64 bits, whould existing
> >code that only looks at 32 bits break ? (for instance doing bit tricks
> >within DCL or would having extra high order bits not make a difference ?
> >
> >or would the move to 64 bit integers be more or less transparent for
> >most DCL (VAXman need not apply, he doesn't do "normal" :-)
> >
> >If it does cause trouble, what sort of uses would break ?
> 
> I would say that it would depend upon how it was implemented.
> 
> 
> -- 
> VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG
> 
> I speak to machines with the voice of humanity.

Yes, I think VAXman has the right idea. OpenVMS implements 64-bit functions and operations to be elective and concurrent within images also using the original 32-bit functions and operations. This is true for most all the traditional programming languages on OpenVMS. There should be no reason that the implementation of DCL could also achieve this flexible programmer friendly design without disturbing previously existent DCL code.

One potential implementation design would be to introduce a new quadword radix symbol %q. %d would remain as an explicit 32-bit radix symbol. DCL continues to assume all operators and variables are 32-bit. But once an expression includes an explicit %q in the enumeration of an operand (or a symbol with the new symbol type QUADINT), then all operators and also the resulting symbol assign are implemented in their 64-bit form. 

To maintain backward compatibility, F$TYPE would continue to return INTEGER for both 32-bit and 64-bit integers. A new lexical could be introduced such as F$NUMTYPE to differentiate between the two integer lengths INTEGER and QUADINT .

Of course DCL would need additional limit checks and error messages for incorrect usage of 32-bit and 64-bit symbols and constants in the various lexicals and math/byte operators. 

Cheers!

Keith Cayemberg