|[TDR] Token-Based Compilers firstname.lastname@example.org (1993-01-20)|
|Re: [TDR] Token-Based Compilers email@example.com (1993-01-23)|
|Re: [TDR] Token-Based Compilers firstname.lastname@example.org (1993-01-25)|
|Re: [TDR] Token-Based Compilers email@example.com.EDU.AU (1993-02-01)|
|From:||firstname.lastname@example.org (Kieron Drake)|
|Organization:||UniSoft Ltd., London, England|
|Date:||Mon, 25 Jan 1993 18:22:55 GMT|
email@example.com (Paul Robinson) writes:
>I'd like to ask what people think of the idea of Compilers that generate
>ficticious machine code, i.e. tokens for an optimized machine which is
>then interpreted on the target.
One of the classic early uses of this technique was by Martin Richards
when he used OCODE as the intermediate code for BCPL compilers. The first
issue (I think it's the first issue) of Software Practice & Experience has
a discussion of the portability issues. (actually it's a bit more complex
than that: he used two levels of intermediate code; intcode & OCODE with
intcode being amazingly simple to interpret so you could get the intcode
version of the compiler up a.s.a.p. and then take time to get your
OCODE-driven back end working). Another reference is "BCPL: The Language
and its Compiler", Richards & Whitby-Strevens.
OCODE is for a fairly simple stack based virtual machine. One can get
pretty good code generated for modern architectures, which have lots of
registers, by simulating register contents as long as possible and using
graph-colouring techniques for register allocation. That gives a fairly
simple back-end which is reasonably configurable across machines of
similar architecture, produces reasonable code quickly and can be
implemented fairly fast. All my opinion/experience, of course.
firstname.lastname@example.org Tel: +44 71 729 3773 (or 071 729 3773 in the UK)
Kieron Drake Fax: +44 71 729 3273 (or 071 729 3273 in the UK)
Senior Consultant, UniSoft Ltd., Spa house, Chapel Place, Rivington Street,
London EC2A 3DQ, UK
Return to the
Search the comp.compilers archives again.