compilation to C [was Re: Java virtual machine...]

Christopher Glaeser <cdg@nullstone.com> writes:


  cdg> f2c is a good case study for illustrating one type of problem
  cdg> with language A to language B translation systems.


Toon already addressed that, I think, and the following.


  cdg> One of the problems with f2c/C performance is that f2c converts
  cdg> some contructs that are common in FORTRAN to constructs that are
  cdg> relatively uncommon in C.


  cdg> Since compiler developers tend to focus on optimizing common
  cdg> constructs, the code generated for f2c translations can be less
  cdg> than is technically possible.


Probably, but I've still seen little evidence. [OSC (?) for SISAL is
another high performance system going through C from a completely
different language which doesn't apparently suffer from it.]


  cdg> Consider the following example:


[...]


  cdg> Note that the loop control variable is declared "static integer"
  cdg> (where "integer" is generally a typedef for "long int").


This is a consequence of not using f2c's `-a' to allow automatic
storage allocation. That flag will avoid the `static' and I confine
my statements about f2c performance to portable code which can use it.


The default is presumably a concession to the large amount of
poorly-written code which wrongly assumes implicit SAVE semantics
(typically through VAXcentricity). The SunPro f77 compiler and
several others do the same, but G77, for instance, doesn't.


Presumably the major weakness of f2c code is likely to be failure to
take advantage of aliasing restrictions, but then native code
compilers often don't either, and many users just won't accept the
restriction even exists.
--

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