Re: Parallel Algol68 compiler

Henry Spencer <henry@zoo.toronto.edu>
1 Mar 1996 14:02:33 -0500

          From comp.compilers

Related articles
Algol68 compiler ? news@chaos.kulnet.kuleuven.ac.be (1996-02-19)
Re: Algol68 compiler ? neitzel@gaertner.de (1996-02-23)
Parallel Algol68 compiler mac@coos.dartmouth.edu (1996-02-27)
Re: Parallel Algol68 compiler hleroy@irisa.fr (1996-03-01)
Re: Parallel Algol68 compiler henry@zoo.toronto.edu (Henry Spencer) (1996-03-01)
| List of all articles for this month |

From: Henry Spencer <henry@zoo.toronto.edu>
Newsgroups: comp.compilers
Date: 1 Mar 1996 14:02:33 -0500
Organization: SP Systems, Toronto
References: 96-02-236 96-02-290 96-02-325
Keywords: parallel

mac@coos.dartmouth.edu (Alex Colvin) writes:
>Early Un*x compilers ran as a number of processes connected by pipes.
>Although this was largely due to address space limits, I suppose it
>might allow some overlap of analysis and I/O.


No, actually the early Unix compilers ran one phase at a time,
connected by temporary files. Remember that early Unix hardware
configurations often could not accommodate more than one big process
in memory; trying to run all the phases simultaneously, connected by
pipes, would have slowed down compiles quite substantially.


> Unfortunately, it looks like C requires that the lexer and
> declaration semantics be carefully synchronized, limiting the
> potential concurrency.


This is not really true, actually. I've written a C parser which had
lexer, parser, and semantics as completely separate passes (joined by
pipes, as it happens, so I can guarantee the separation).


The problem Alex is alluding to is typedef. But typedef is not
semantics; it is context-dependent syntax. It's not hard to
determine, purely at the syntactic level, when a type name is being
declared. The tricky part is that you need to feed that knowledge
back into the parsing.


The parsing technology I was using was context-independent, so I
fudged a little. A tiny bit of "front end" code consulted a table of
type names and turned ID into TYPEID where necessary, before the
parser saw it. When the declaration parsing saw a type-name
declaration, it invoked a little bit of code which maintained the
type-name table. (Nested scopes did complicate the table slightly.)
--
Henry Spencer, henry@zoo.toronto.edu
--


Post a followup to this message

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