tneff@bfmny0.UUCP (Tom Neff) (06/09/89)
In article <4454@ficc.uu.net> karl@ficc.uu.net (karl lehenbauer) writes: > ... We do a lot of stuff that has to be >FORTRAN-callable, and *all* the parameters for a PL/M routine that's FORTRAN- >callable have to be pointers, so a lot of the benefits of data type checking >by the compiler are lost to us. This is not actually true. Intel FORT86 supports the %VAL construct as defined in F77, so you can say SUBROUTINE MYSUB(%VAL(X),%VAL(I),%VAL(J)) REAL*8 X INTEGER I,J ... END ... SUBROUTINE MAIN(RCODE) ... CALL MYSUB(%VAL(OURX),%VAL(2),%VAL(35)) ... and the stuff will get passed by value. If MYSUB or MAIN were in PL/M it would handle its end of the interface with pass-by-value. The one annoyance is LINK86's overzealous TYPDEF frenzy. If you pass %VAL(INTEGER*2) you had better declare your PL/M routine as expecting INTEGER not WORD or you'll get TYPE MISMATCH. For 32 bit quantities there's no escape, except by compiling one or both modules with $NOTYPE. As I point out in comp.realtime (hmm, sometimes crossposting IS a good idea <grin>), *nobody* does a good job of parameter type checking with Intel FORTRAN because it's all done at link time. Only FORTRAN-FORTRAN and C-C and PL/M-PL/M are guaranteed to give meaningful results on the TYPDEF level. (I think PASCAL-FORTRAN did OK the one time I checked. Lotta projects with THAT combo I'll bet! <grin>) So for interfacing with FORTRAN, C is no better a choice than PL/M -- UNLESS you work out an automated way of generating <fortstuff.h> extern declarations from parsing the FORTRAN source code, which seems like a good tool but a lot of work. -- You may redistribute this article only to those who may freely do likewise. -- Tom Neff UUCP: ...!uunet!bfmny0!tneff "Truisms aren't everything." Internet: tneff@bfmny0.UU.NET