Re: Pros and cons of high-level intermediate languages

sewardj@cs.man.ac.uk (Julian Seward)
Sun, 26 Jul 1992 11:30:52 GMT

          From comp.compilers

Related articles
[11 earlier articles]
Re: Pros and cons of high-level intermediate languages acha@CS.CMU.EDU (1992-07-24)
Re: Pros and cons of high-level intermediate languages graham@maths.su.oz.au (1992-07-25)
Re: Pros and cons of high-level intermediate languages fjh@munta.cs.mu.OZ.AU (1992-07-25)
Re: Pros and cons of high-level intermediate languages moss@cs.umass.edu (1992-07-25)
Re: Pros and cons of high-level intermediate languages jfc@athena.mit.edu (1992-07-25)
Re: Pros and cons of high-level intermediate languages scott@bbx.basis.com (1992-07-25)
Re: Pros and cons of high-level intermediate languages sewardj@cs.man.ac.uk (1992-07-26)
Re: Pros and cons of high-level intermediate languages ridoux@irisa.fr (1992-07-27)
Re: Pros and cons of high-level intermediate languages gat@forsight.jpl.nasa.gov (1992-07-29)
Re: Pros and cons of high-level intermediate languages moss@cs.umass.edu (1992-07-30)
Re: Pros and cons of high-level intermediate languages boehm@parc.xerox.com (1992-07-30)
Re: Pros and cons of high-level intermediate languages graham@maths.su.oz.au (1992-08-02)
Re: Pros and cons of high-level intermediate languages ridoux@irisa.fr (1992-08-04)
[10 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: sewardj@cs.man.ac.uk (Julian Seward)
Organization: Department of Computer Science, University of Manchester
Date: Sun, 26 Jul 1992 11:30:52 GMT
Keywords: bibliography, translator
References: 92-07-068 92-07-084

Graham Matthews writes:


| (Olivier Ridoux) writes:
| >d) There is no first-class label data-type. One can neither store and
| >read labels, nor goto stored labels.
|
| I think you will find that gcc 2.X allows you to have arrays of labels.
| Any gcc experts out there to confirm this?


I am surprised no-one has picked up on this. Sure, C doesn't allow labels
as first class citizens, but procedure names *are*. The Glasgow Haskell
Compiler uses C as a back end. Each basic block is compiled into a
parameter-less C procedure. When a basic block is done, it *returns* the
address of the next block to be executed (which is some C procedure). The
whole system is driven by a magic 1-line "interpreter" like this:


      while (TRUE) { cont = (*cont)(); }


so that "cont" is the address of the next code block to be executed. This
works, is uses no non-standard extensions, but is somewhat inefficient.
At the cost of portability, one can use non-standard extensions in GCC
1.XX and 2.X to genuinely to direct jumps from one code block to the next,
and various other optimisations like suppressing register load/saves.


All this magic is described in Simon L Peyton Jones's paper.


It should be pointed out this is not a new idea. Apparently Guy Steele
used this in the Rabbit compiler for Scheme, and also for a SML compiler
in the reference below.


Jules


-------------------


D Tarditi, A Acharya and P Lee [March 1991]. "No assembly required:
compiling Standard ML to C", School of Computer Science,
Carnegie Mellon University.


Simon L Peyton Jones [1992]. "Implementing lazy functional languages on
stock hardware: the Spineless Tagless G-machine". Department of Computing
Science, University of Glasgow, UK. To appear in the Journal of
Functional Programming, and available by anonymous FTP from
ftp.dcs.glasgow.ac.uk:/pub/glasgow-fp/papers/spineless-tagless-gmachine.dvi
[This is known as continuation passing form; Andrew Appel's book which was
discussed here recently is all about how he built an ML compiler that works
that way. -John]
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.