Re: Non-sequential compilation.

rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Mon, 4 Oct 1993 15:01:57 GMT

          From comp.compilers

Related articles
Non-sequential compilation. KODIS@delphi.com (1993-09-18)
Re: Non-sequential compilation. macrakis@osf.org (1993-09-21)
Re: Non-sequential compilation. cliffc@rice.edu (1993-09-21)
Re: Non-sequential compilation. pcg@aber.ac.uk (1993-09-21)
Re: Non-sequential compilation. conway@mundil.cs.mu.OZ.AU (1993-09-22)
Re: Non-sequential compilation. gafter@mri.com (1993-09-27)
Re: Non-sequential compilation. rbe@yrloc.ipsa.reuter.COM (1993-10-04)
| List of all articles for this month |
Newsgroups: comp.compilers
From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Keywords: assembler, parallel, APL, parse
Organization: Snake Island Research Inc, Toronto
References: 93-09-068
Date: Mon, 4 Oct 1993 15:01:57 GMT

> My question is, has any research been conducted into an "all-at-once"
> translation scheme, where a source file is completely read or mapped into
> memory before translation begins?


This technique is quite common for compilers written in APL or J.
We tend to treat the entire compilation unit as a text matrix, then
crunch it in parallel. See my papers in:
      "Arrays, Functional Languages, and Parallel Systems", Kluwer Academic,
        1991
        "ACM SIGAPL Quote Quad APL90 Conference Proceedings, Vol. 20, no. 4(?)"


This describes a simple APL compiler which uses a parallel tokenizer.


A number of us have also built parallel assemblers which work sort of
as follows:
      a. Extract all labels from the source. They are places where
              the first column is non-blank.
      b. Rotate each row of the source to the first non-blank after the
            first blank. This aligns op codes to the first column of the
              matrix.
      c. Extract op codes and deal with them.
      d. Rotate again to align operands.
      e. Extract operands and deal with them.
      f. Deal with comments if you desire.


Some real life assemblers get a bit messy due to things like short vs
long branches, but it is surprising how much can be done in parallel.
The code is a LOT simpler, as well.


Bob




Robert Bernecky rbe@yrloc.ipsa.reuter.com
Snake Island Research Inc (416) 203-0854
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9
Canada
--


Post a followup to this message

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