From: Steve Lionel on 26 Nov 2009 11:00 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 26 Nov 2009 14:30 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 26 Nov 2009 14:58 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 26 Nov 2009 15:32 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 26 Nov 2009 15:40
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. |