Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!mips!dimacs.rutgers.edu!rutgers!modus!gear!cadlab!martelli From: martelli@cadlab.sublink.ORG (Alex Martelli) Newsgroups: comp.lang.c Subject: Re: low level optimization Message-ID: <805@cadlab.sublink.ORG> Date: 29 Apr 91 16:31:03 GMT References: <1991Apr17.225944.15261@zoo.toronto.edu> <22720@lanl.gov> <5079@cernvax.cern.ch> Organization: CAD.LAB, Bologna, Italia Lines: 40 burow@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@cadlab.sublink.org, (home:) alex@am.sublink.org Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434; Fax: ++39 (51) 366964 (work only), Fidonet: 332/401.3 (home only).