Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!gatech!bloom-beacon!think!ames!ucbcad!ucbvax!SUN.COM!crb
From: crb@SUN.COM (Chuck Bilbe)
Newsgroups: comp.lang.modula2
Subject: Translating M2 -> C
Message-ID: <8707171628.AA02971@odysseus.sun.com>
Date: Fri, 17-Jul-87 12:28:09 EDT
Article-I.D.: odysseus.8707171628.AA02971
Posted: Fri Jul 17 12:28:09 1987
Date-Received: Sat, 18-Jul-87 14:54:33 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 41

In regard to Duncan White's recent note proposing a Modula-2 to C translation
scheme --- no, it isn't a crackpot scheme.  That would make me a crackpot.

I envisioned and supervised just such a project at Hewlett-Packard
Logic Systems Division in 1984.  We built the compiler by "retargeting"
the Zurich M2M compiler (written in Pascal) and driving it with a shell script
under HP-UX.

Here are some of the things we found out:

PRO
  Up and running in two (!) months.
  Object code quality not shabby at all.  C makes a fine assembly language.
  Use of C register variables provided good support for a simulated Stack Pointer
     and simulated Frame Pointer.
  "Intermediate" object code (e.g. C) transportable to virtually any machine.
  Semantic complexity of the "code generator" (c producer) is quite low.
  It was easy to arrange for inter-language ( C <==> Modula-2 ) calling.

CON
  Extremely slow (we're talking molasses in January) compilation rates.
  Virtually no support for decent high-level debugging (info lost in translation)
  Difficult, politically, to convince people it was a "real" compiler.
  Since C doesn't support nested scopes, activation records couldn't be on C stack,
    and a "parallel" stack had to be implemented as a linked list of structures.
  Since C doesn't support name conflicts at outer level, symbolic info was lost because
    names had to be hoked-up (e.g. InOut.WriteLn  might be "InOut00002WriteLn") so the
    linker wouldn't complain.
  We had some difficulty in translating function within expressions and still preserving
    the original evaluation ordering.
  We never did figure out (nor were we really interested in) a decent implementation of
    coroutines.
  We had some difficulties with the C compiler, stretching it in ways it wasn't used to.
    (overflowing name tables, too many labels, ... etc.)
  Don't expect the resulting C code to be understandable or readable by humans.  It isn't.
    Of course, that's often true of human-produced C code  (:-)  

Overall, it was worth doing;  I do not consider it a way to achieve a production 
compiler but not a bad way to bootstrap a real one.

-- Chuck Bilbe