[Info-vax] Userland programming languages on VMS.

[Arne Vajhøj]

On 1/29/2022 1:53 AM, George Cornelius wrote:
> Bill Gunshannon <bill.gunshannon at gmail.com> wrote:
>> On 1/28/22 14:46, Arne Vajh?j wrote:
>>> On 1/28/2022 12:37 PM, John Reagan wrote:
>>>> On Friday, January 28, 2022 at 8:51:57 AM UTC-5, Arne Vajh?j wrote:
>>>>> On 1/28/2022 4:06 AM, cao... at pitbulluk.org wrote:
>>>>>> On Friday, January 28, 2022 at 6:29:10 AM UTC, Steven Schweda wrote:
>>>>>>>> Which I do not consider exotic.
>>>>>>> Sure, fine, but look at the results from the current blend of (what
>>>>>>> are, I assume) defaults. Whether or not better results are so "easy",
>>>>>>> the existing situation (mess) is the existing situation (mess).
>>>>>>>
>>>>>>> As I said, "unrealistic". That was an inference, not a postulate.
>>>>>>
>>>>>> Aren't C/C++ the only VMS languages capable of using the full 64 bit
>>>>>> address space?
>>>>>> Perhaps some others are (partially) capable but it doesn't look at
>>>>>> all convenient.
>>>>>> Pascal has IADDRESS64 in addition to IADDRESS but why bother to call
>>>>>> a _64 system service when you can't really do much else with it?
>>>>> I believe Fortran supports usage of P2 space.
>>>>>
>>>> Fortran lets you allocate COMMON in P2 and it has the CDEC$ POINTER64
>>>> (or however it is spelled)
>>>> attribute.?? You can have "top level" 64-bit pointers but you can't
>>>> get 64-bit pointers as fields in a structure.
>>>
>>> Real Fortran programmer does not use pointers.
>>>
>>> :-)
>>>
>>> Example with common:
>>>
>>> $ type f64.for
>>>   ????? program f64
>>>   ????? implicit none
>>>   ????? real*8 x(10),y(10)
>>>   ????? common /cx/x
>>>   ????? !DEC$ATTRIBUTES ADDRESS64::cy
>>>   ????? common /cy/y
>>>   ????? write(*,'(1x,z16.16)') %loc(x)
>>>   ????? write(*,'(1x,z16.16)') %loc(y)
>>>   ????? end
>>> $ for f64
>>> $ link f64
>>> $ run f64
>>> 0000000000040000
>>> 0000000080000000
>>>
>>
>> I ran that thru every FORTRAN compiler I had.  Sorry, it's not
>> FORTRAN.
> 
> Works on Eisner.
> 
> $ show sys/noproc
> OpenVMS V8.4-2L2  on node EISNER   29-JAN-2022 [...]
> 
> Here's the memory layout synopsis from a linker map:
> 
> Virtual memory allocated:                         00010000 0005FFFF 00050000 (327680. bytes, 640. pages)
> 64-Bit Virtual memory allocated:                  00000000 00000000 00000000
>                                                    80000000 80010000 00010000 (65536. bytes, 128. pages)
> 
> The example, though, shows too small an allocation to escape 32 bit address space.

I consider 0000000080000000 to be 64 bit space.

0000000000000000 - 000000007FFFFFFF is P0 and P1 space
FFFFFFFF80000000 - FFFFFFFFFFFFFFFF is S0 and S1 space
0000000080000000 and upward is P2 space

Arne