[Info-vax] Userland programming languages on VMS.

[Dave Froble]

On 1/29/2022 8:23 AM, Bill Gunshannon wrote:
> On 1/29/22 01:53, 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.
>>
>
> Just because a non-Fortran compiler accepts it doesn't make it Fortran.
>
> bill
>

"non-Fortran compiler" ???????????????????
-
Oh, no, Simon has been cloned.  We are doomed!

:-)

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486