%LOC and %VAL availability
in [Fortran]
|
From: Ken Fairfield on 25 Nov 2009 17:13 On Nov 24, 11:01 am, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > James Tursa <aclassyguywithakno...(a)hotmail.com> wrote: > > The non-standard %LOC() and %VAL() constructs are available in the > > Intel Fortran and Compaq Fortran compilers that I have (32-bit, > > WinXP). Are these constructs available in other compilers such as > > gfortran, f95, etc? What about linux, mac, etc.? If not, is there a > > workaround for this functionality? I am writing a package for others > > to use and would like it to run in other environments out of the box > > if possible. Thanks. > > These came with VAX (yes VAX, not VMS) that tried to define standard > calling conventions. [...] Glen, I surprised you would try to make such a distinction between VAX and VMS. They were, after all, developed together, one for the other, so to speak. And were it me, I'd have made the opposite claim, that it was VMS (or more correctly VAX/VMS as it was know at the time), the software, not VAX, the hardware, that made %LOC, %VAL and %DESCR available (and useful). The hardware could pretty much care less, except for the mapping of various addressing/indirection modes, etc., in VAX Macro (Macro-32). But in Macro, those %xxxx names weren't present. So VAX/VMS (and all subsequent versions of VMS on VAX, Alpha and IA64), or just VMS. Not just VAX. -Ken
From: glen herrmannsfeldt on 25 Nov 2009 18:21 Ken Fairfield <ken.fairfield(a)gmail.com> wrote: (snip, I wrote) >> These came with VAX (yes VAX, not VMS) that tried to define standard >> calling conventions. ?[...] > Glen, I surprised you would try to make such a distinction > between VAX and VMS. They were, after all, developed together, > one for the other, so to speak. And were it me, I'd have made > the opposite claim, that it was VMS (or more correctly VAX/VMS > as it was know at the time), the software, not VAX, the hardware, > that made %LOC, %VAL and %DESCR available (and useful). I once got it wrong, but now don't have the reference. I believe I asked once on comp.os.vms and was told that it was VAX. I have "VAX Architecture Reference Manual" by Timothy Leonard, and it isn't in there. > The hardware could pretty much care less, except for the mapping of > various addressing/indirection modes, etc., in VAX Macro (Macro-32). > But in Macro, those %xxxx names weren't present. > So VAX/VMS (and all subsequent versions of VMS on VAX, Alpha > and IA64), or just VMS. Not just VAX. As I don't have a reference, it is hard to say. If the idea of having a language independent call convention came from the hardware people, it is possible. I never used VAX/Unix, and don't know how they did calls there. Even if it was a VAX standard, used by VMS, subsequent ports of VMS would have to support them for software porting purposes. Defining it with the hardware would make assembly code more portable between different OS. -- glen
From: glen herrmannsfeldt on 26 Nov 2009 00:12 Ken Fairfield <ken.fairfield(a)gmail.com> wrote: (snip) > Glen, I surprised you would try to make such a distinction > between VAX and VMS. They were, after all, developed together, > one for the other, so to speak. 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. Though the % prefix will conflict with the PL/I preprocessor if one tries to do it for PL/I. -- glen
From: James Tursa on 26 Nov 2009 03:08 On Wed, 25 Nov 2009 06:56:49 -0800 (PST), GaryScott <garylscott(a)sbcglobal.net> wrote: > >:( would be better if matlab didn't treat Fortran as a second class >citizen and created a proper binding. Well, yes, there is that. If you look at their Fortran doc some of it isn't even syntactically correct for F77. And the Fortran example they give in the doc for linking to their BLAS and LAPACK routines does not work at all for the Intel Fortran compiler, their only officially supported Fortran compiler, because their libraries still use the old name mangling of @number_of_argument_bytes at the end while the Intel Fortran compiler does not do that by default. So if you copy & paste their exact example from the doc and use their exact compile commands it will not work (need to add the /Gm compile flag to get that behavior and get it to link ... took me awhile to figure that one out). But overall, I am not complaining much about it since at least they *do* offer Fortran support. Mostly I write Fortran code that the MATLAB folks left out of their official product or other helpful Fortran code (like the code that spawned this thread) and post it to their file sharing system for others to download and use. James Tursa
From: Tim E. Sneddon on 26 Nov 2009 08:45
glen herrmannsfeldt wrote: > Ken Fairfield <ken.fairfield(a)gmail.com> wrote: > (snip) > >> Glen, I surprised you would try to make such a distinction >> between VAX and VMS. They were, after all, developed together, >> one for the other, so to speak. > > 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. > > Though the % prefix will conflict with the PL/I preprocessor > if one tries to do it for PL/I. > 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. I have my VAX Architecture Handbook out too and it simply notes the Fortran built-ins as an example. For BASIC there is the BY keyword that can be followed by DESC, REF or VALUE to indicate the mechanism. Pascal has %IMMED, $REF and %DESC (I think). BLISS passes by value by default (like C). There is a %REF( ) built-in, but no %DESC as it is expected that BLISS programmers will build descriptors themselves (again, the same as C). PL/I provides DESCRIPTOR, REFERENCE and VALUE built-in functions. As for %LOC...well, Pascal has IADDRESS and BASIC has LOC. In BLISS everything is an address that has to be explicitly de-referenced with a '.'. C has the '&' operator and PL/I has ADDR(). Of course there is nothing like that for MACRO-32 where it is expected that the programmer will load the stack with the relevant values, whether they be values, references or references to descriptors. Tim. |