[Info-vax] 64 bit DCL ?

[Bob Gezelter]

On Friday, January 16, 2015 at 11:41:00 AM UTC-5, Keith Cayemberg wrote:
> 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

JF,

I concur with Keith and Brian: A change which breaks compatibility would be a bad idea. It is not that the errors could not be dealt with. Rather, it is the simple fact that a large number of sites are relying on DCL that is not of their own making. Some of this is received from vendors, some from contributed programs, and some authored by long-departed staff.

An incompatible change which breaks code leaves many users in an unacceptable position. A new datatype is possible, but it does add (as Hoff has mentioned in other threads) to a degree of code cruft, which is also undesirable.

- Bob Gezelter, http://www.rlgsc.com