From: Steve Lionel on
Tim E. Sneddon wrote:

> The %VAL, %DESC and %REF keywords were not used for all languages.
> They are simply Fortran's way of supporting the argument passing
> mechanisms supported by the OpenVMS Calling Standard.

All VMS languages were pretty much required to have some syntax for
specifying the passing mechanism. The spellings shown here were used
for VAX FORTRAN, but as Tim says, other languages had their own syntax,
which was not always something that looked like a function call
(ignoring the percent). VAX PASCAL, for example, used attributes in
square brackets, if I recall correctly.

It was a wonderful thing - an operating system designed from the start
to have a rich multi-language environment and a single set of calling
conventions. I've never seen such a thing since.

I'll comment that other Fortran vendors adopted LOC(), without the %,
and the DEC compilers eventually supported that too. Unlike %LOC, which
could be used anywhere, %VAL, %REF and %DESC were usable only in actual
argument lists.

--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH

For email address, replace "invalid" with "com"

User communities for Intel Software Development Products
http://software.intel.com/en-us/forums/
Intel Software Development Products Support
http://software.intel.com/sites/support/
My Fortran blog
http://www.intel.com/software/drfortran
From: glen herrmannsfeldt on
Tim E. Sneddon <tim.sneddon(a)bigpond.com> wrote:
(snip, I wrote)

>> OK, it is in "VAX11/780 Architecture Handbook", copyright 1977.

>> Appendix C, "Procedure Calling and Condition Handling"

>> The description of the calling convention says "VAX-11" thoughout.
>> For Condition Handling it says VAX/VMS. It looks to me like someone
>> wanted the calling convention to be OS independent, but realized
>> that condition handling was VMS dependent.
(snip)

> The %VAL, %DESC and %REF keywords were not used for all languages.
> They are simply Fortran's way of supporting the argument passing
> mechanisms supported by the OpenVMS Calling Standard.
(snip)

"Goals for the VAX-11 calling standard are:

1. The standard must be applicable to all of the intermodule
CALLable interfaces in the VAX-11 software system.
Specifically, the standard considers the requirements of
BASIC, COBOL, FORTRAN, BLISS, assembler, and CALLs to
the operating system."

(and later)

... "Each language is augmented to provide the following
compile-time intrinsic functions:

%VAL(arg) -- Corresponding argument list entry is the actual
32 bit value of the argument arg, as defined in
the language."

(continuing on for %REF and %DESCR. No mention of %LOC)

-- glen
From: dpb on
glen herrmannsfeldt wrote:
> Tim E. Sneddon <tim.sneddon(a)bigpond.com> wrote:
> (snip, I wrote)
>
.... snip ...

why do the words "tempest" and "teapot" seem to come to my mind I
wonder??? ;)

--
From: glen herrmannsfeldt on
dpb <none(a)non.net> wrote:

> why do the words "tempest" and "teapot" seem to come to my
> mind I wonder??? ;)

I wonder how different things would be if Intel had the idea
of a system independent calling convention. VAX and 8086 came
out at about the same time, though presumably they were in
development for some years before.

Mabye even no need for C interoperability in Fortran!
(Assume other processors also followed along.)

-- glen
From: nmm1 on
In article <hemokm$1a2$1(a)naig.caltech.edu>,
glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote:
>dpb <none(a)non.net> wrote:
>
>> why do the words "tempest" and "teapot" seem to come to my
>> mind I wonder??? ;)
>
>I wonder how different things would be if Intel had the idea
>of a system independent calling convention. VAX and 8086 came
>out at about the same time, though presumably they were in
>development for some years before.

Have you EVER been in a project to design such a thing? I have.

>Mabye even no need for C interoperability in Fortran!
>(Assume other processors also followed along.)

%deity preserve me :-(

The thing that kills you is semantic incompatibility, especially
conceptual incompatibility. E.g. Cobol requires integer overflow
to the trapped, and Java forbids it. Fortran finalisers are
called in different places from C++ destructors. And so on.


Regards,
Nick Maclaren.