low level optimization

Alex Martelli martelli at cadlab.sublink.ORG
Tue Apr 30 02:31:03 AEST 1991


burow at cernvax.cern.ch (burkhard burow) writes:
	...
:QQQQuestion: The clarification I ask for above is actually a serious one, for
:I'd like to know if with my pointer freedom in C, I can pass arguments to a
:FORTRAN routine which will blow up, because of its optimizations based on
:restrictions in FORTRAN.
You can, but you can also blow up Fortran from itself quite easily, i.e. any
'CALL ROUT(X,X)' or 'COMMON/A/X ... CALL TINE(X)' *could* cause the blowup.
Such aliasing is FORBIDDEN in Fortran, but ENFORCING the prohibition is left
to mysterious runtime errors in most cases... just like, in C, free()ing a
pointer NOT obtained via malloc(), or, in any language, using an index out
of range to address an array (indeed, some Fortran compilers will optionally
do array-index-checking, and some malloc()/free() packages will check for
sanity, so I assume somewhere there must exist a compiler that will do some
checks and output error messages on aliasing, though I know of none).

:QQQQuestion: Lots of manuals have little sections on calling and linking
:different languages within the same program. How many people out there actually
:do this sort of thing? e.g. How many people out there use C, handling the messy
:jobs of i/o, user interface, etc., as a frontend to number crunching FORTRAN
:routines? It doesn't matter whether you call the FORTRAN routines because of
:performance reasons, or as in my case, because they exist and work.
I do it the other way 'round, i.e. use C as the backend (for graphics, OS
access, all sorts of algorithms-and-data-types sort of work) for Fortran
programs; it's always Fortran calling C, never the other way around.  As the
fraction of C grows (mostly a reflection of the bad implementations of Fortran
on workstation-class machines, that we observe), SOME C->Ftn cases appear; and
I would indeed like some automated/C-macro approach to such interfacing, just
as I have built for C routines intended to be called from Fortran.  The only
hard problem I see is passing CHARACTER arguments - it's a very convoluted
task in the Ftn->C direction (to keep it portable between 12+ platforms), I
just have not devoted enough work to the C->Ftn direction, so far.  I have
seen your "cfortran" stuff, one month ago, but I have not delved deeply enough
into it to see how hard/easy it would be to generaliza it to Apollo, OS/2, HP,
Sun, IBM RS/6000, etc etc...
-- 
Alex Martelli - CAD.LAB s.p.a., v. Stalingrado 53, Bologna, Italia
Email: (work:) martelli at cadlab.sublink.org, (home:) alex at am.sublink.org
Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434; 
Fax: ++39 (51) 366964 (work only), Fidonet: 332/401.3 (home only).



More information about the Comp.lang.c mailing list