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