Re: Using C as an UNCOL

Dave Lloyd (Dave@occl-cam.demon.co.uk) wrote:


>> I'm surprised no one has mentioned C as a resonably sucessful
>> multi-langauge multi-target UNCOL. f2c,p2c,m2c, Scheme->C, sml2c,
>> Mercury, ghc, .... all


> Foot shot with the first example! C is terribly limited
> in scope and has some really nasty holes in its type
> system. Important information gets lost when squeezing
> down to C. Net result is that if you feed f2c to a good
> C compiler, you will do worse on the sort of numeric
> fortran code than if you have a natural Fortran compiler
> which understands complex arithmetic, arrays, fortran
> no-alias parameter passing, equivalence and common blocks,
> loops with a defined counter. Sure you can reconstruct
> most of this with decent static analysis but it is harder
> (for which read more cases are excluded on reasonable
> grounds of paranoia) than for a Fortran compiler starting
> with this information.


> As illustration, g77 produces substantially better code than f2c+gcc.


You probably mean that _g77-0.5.18_ produces better code than f2c +
gcc. Note that it has taken "us", i.e. the people interested in
g77, quite a few drastic steps to get g77 to produce better code
than f2c + gcc _with the same optimisation flags passed to g77 and
gcc_ - just read the g77-0.5.18 release notes.


The reason for this is that f2c is a Fortran _compiler_, not a
one-to-one Fortran-to-C translator; therefore, it as well can take
advantage of the knowledge about the source any Fortran compiler
has. Sometimes, this knowledge is not expressible in C, but in most
cases, it is.


But even g77-0.5.18 doesn't make use of the noalias-parameter
passing, simply because that concept is not supported by the backend
common to all GNU compilers. John Carr (jfc@MIT.EDU) is working on
this, and the preliminary results I've seen are promising.


> The situation is more absurd with Fortran 90 which provides more powerful
> arrays and extensive array syntax that can be highly optimised with
> comparatively cheap analysis (or for that matter directly invoke
> hand-optimised BLAS).


Good Fortran compilers (on systems where the vendor has complete
control, like Cray) indeed do this: calling BLAS routines when
pattern recognition determines that they can be substituted.
Fortran 90 is not a prerequisite for that.


--
Toon Moene (toon@moene.indiv.nluug.nl) URL: http://www.knmi.nl/hirlam
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
--

Return to the comp.compilers page.
Search the comp.compilers archives again.