Related articles |
---|
Literature on OOP code generation ? kai@ifi.uio.no (1991-03-05) |
Re: Literature on OOP code generation ? beemster@fwi.uva.nl (1991-03-11) |
Newsgroups: | comp.compilers |
From: | beemster@fwi.uva.nl (Marcel Beemster) |
X-Organisation: | Faculty of Mathematics & Computer Science University of Amsterdam Kruislaan 403 NL-1098 SJ Amsterdam The Netherlands |
X-Telex: | 10262 hef nl |
Keywords: | optimize, OOP |
Organization: | Compilers Central |
X-Fax: | +31 20 525 7490 |
Date: | Mon, 11 Mar 91 09:07:38 +0100 |
X-Phone: | +31 20 525 7463 |
>Could anyone point me at some good books/articles on code generation and/or
>runtime library design for OOL ?
You may want to look up my article in the proceedings of the PRISMA
Workshop:
Marcel Beemster, "Back-end Aspects of a Portable POOL-X implementation"
Also some other papers in the same proceedings may be of interest.
Unfortunately the publishing of the proceedings has not yet been finalized.
If you are interested in a LaTeX source copy of the article send me a mail
(beemster@fwi.uva.nl).
The article describes both code generation and run-time support for the
parallel object oriented language POOL-X. The system runs on the parallel
POOMA-machine, a 100-node distributed memory machine. The article describes
how POOL-X sources are compiled into C and the run-time support library.
Compilation into C provides machine independance of the compiled code.
Portability of the run-time-support system is also attained by writing it in
C, but machine independence is much harder here because of the many different
design parameters of parallel distributed memory machines. Yet, we have been
able to make the system run on three different kinds of such machines: The
POOMA machine (68020 based), a transputer based machine, and a network of
SUN-stations. Of course the system also runs on any decent (from the
C-hackers point of view) sequential machine.
The article describes lots of details about distributed garbage collection,
the synchronization detector, software engeneering aspects of developing such
a system, maintaining portability, the run-time expression compiler (also
portable, and NOT based on interpretation), and more.
>[I was under the impression that other than the issue of binding the addresses
>of methods, the issues are pretty standard. -John]
Ah, yes.... Ever written a garbage collector, John? For a parallel
machine?
++marcel beemster@fwi.uva.nl
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.