[Info-vax] 64 bit DCL ?

[David Froble]

VAXman- @SendSpamHere.ORG wrote:
> In article <571cef69-9865-4c6c-bdba-6c00dc1d8737 at googlegroups.com>, Keith Cayemberg <keith.cayemberg at arcor.de> writes:
>>>> I would say that it would depend upon how it was implemented.
>>>> =20
>>>> =20
>>>> --=20
>>>> VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(do=
>> t)ORG
>>>> =20
>>>> I speak to machines with the voice of humanity.
>>> =20
>>> Yes, I think VAXman has the right idea. OpenVMS implements 64-bit functio=
>> ns and operations to be elective and concurrent within images also using th=
>> e original 32-bit functions and operations. This is true for most all the t=
>> raditional programming languages on OpenVMS. There should be no reason that=
>> the implementation of DCL could also achieve this flexible programmer frie=
>> ndly design without disturbing previously existent DCL code.
>>> =20
>>> 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 co=
>> ntinues to assume all operators and variables are 32-bit. But once an expre=
>> ssion 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 resulti=
>> ng symbol assign are implemented in their 64-bit form.=20
>>> =20
>>> To maintain backward compatibility, F$TYPE would continue to return INTEG=
>> ER for both 32-bit and 64-bit integers. A new lexical could be introduced s=
>> uch as F$NUMTYPE to differentiate between the two integer lengths INTEGER a=
>> nd QUADINT .
>>> =20
>>> Of course DCL would need additional limit checks and error messages for i=
>> ncorrect usage of 32-bit and 64-bit symbols and constants in the various le=
>> xicals and math/byte operators.=20
>>> =20
>>> Cheers!
>>> =20
>>> Keith Cayemberg
>> Hmmm, I have reconsidered the choice of QUADINT as a reserved word for DCL.=
>> It would probably be more correct to use QUADWORD or just QUAD.
> 
> Perhaps, something as simple as...
> 
> $ ENABLE QUADWORD
> $ DISABLE QUADWORD
> 
> wherein all integer math would then be 64 bit.  The integer symbol maintains
> a storage of a 4 byte value.  If quadword mode is enabled, the integer symbol
> would maintain 8 bytes.  In fact, I'd see a change where the integer symbol
> would be modified to maintain 8 bytes sign-extended.  Then, traditional 32
> bit integer math could go unchanged.  
> 
> Of course, there would be changes needed in DCL when/where math upon these
> symbols is performed but such changes could be made transparent as well and
> enabled with syntax such as I've described.
> 

See.  It's not so hard.  No rockets involved ....