🚀 go-pugleaf

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