🚀 go-pugleaf

In article <15U2GTBggpc2@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:

  I have never seen a public domain Fortran compiler. [ ...]  If Fortran is
  so easy, where are the compilers for PCs? There are several times as many
  C compilers available. [ ... ] Tell you what... you write a PD Fortran
  compiler and we can compare it in complexity with a PD C compiler and see
  who wins.

I hate to say it, but for the sake of exactness, I understand that there is
a good quality fortran to C compiler/translator (f2c), just like p2c is a
good quality pascal/modula 2 to C translator. I also think that the MIPS
Fortran compiler is actually a fortran to C translator (but of course it is
proprietary).

On the more general subject of the thread: I have been amused by this
discussion of Fortran vs. C optimization; first of all C was not born as an
application language, but as a system implementation language (MOHLL).  As
such attempts to convert/misrepresent it into a safe, application oriented
good-for-all tool are just funny. Fortran is the C of numerical calculations; as far
as these are concerned, it is more application oriented, but always ata
pretty low level.

To me, having a low level program in C or Fortran, an optimizer that tries
to understand it and decompile it into an higher level form, apply program
transformations to the high level form, and then compile it to machine
language, is just a laughable waste of time and talent. Were it not for the
'dusty deck' problem, which means lots of dollars. For example, if you have
a classic a matrix multiply 3 nested loop, on a vector machine the most
efficient nesting order of such loops is different from a non vector machine.
You want to say 'matrix multiply', not give one possible implementation, and
then have the optimizer "understand" it is a matrix multiply, and then
generate the code corresponding to a more efficient (for that machine)
equivalent version.

As a research endeavour, or for points of principle, there do exist higher
level, application oriented languages, and surely others could be designed,
that provide an optimizer with the opportunity to devise intelligent
strategies for efficient execution, without the decompilation phase, which is
always fraught with hazards and inefficiencies.

My position on this is:

1) If you want to delegate optimization to a program, have a language
designed for this. Decompilation is hazardous. Code generation is already
difficult enough.

2) If you want to turn dusty decks into higher level, more easily optimizable
language, use a programmer's assistant, source rewriting tools, whatever.
Don't confuse a code reorganizer with a compiler's code generator.

3) Leave alone low level languages like C which have been designed to give
programmer control over the generated code, where the programmer knows the
compiler will be a faithful, dumb, *obedient* servant of the source code.

Discussing whether C or Fortran can more easily be decompiled into an higher
level more application oriented language is IMNHO very silly, especially if
the discussion centers around such microscopic issues as to whether element
access to vectors should be via pointers or subscripts, when there is almost
never the need to access each element one by one to express numeric codes
(oh APL!).
-- 
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk