On Fri, 8 Feb 2019 08:37:33 -0500, Matthias Felleisen
<matth...@felleisen.org> wrote:
>
>> On Feb 6, 2019, at 3:19 PM, George Neuner <gneun...@comcast.net> wrote:
>>
>> The idea that a compiler should be structured as multiple passes each
>> doing just one clearly defined thing is quite old. I don't have
>> references, but I recall some of these ideas being floated in the late
>> 80's, early 90's [when I was in school].
>>
>> Interestingly, LLVM began (circa ~2000) with similar notions that the
>> compiler should be highly modular and composed of many (relatively
>> simple) passes. Unfortunately, they quickly discovered that, for a C
>> compiler at least, having too many passes makes the compiler very slow
>> - even on fast machines. Relatively quickly they started combining
>> the simple passes to reduce the running time.
>
>
>I strongly recommend that you read the article(s) to find out how
>different nanopasses are from the multiple-pass compilers, which
>probably date back to the late 60s at least. — Matthias
I did read the article and it seems to me that the "new idea" is the
declarative tool generator framework rather than the so-called
"nanopass" approach.
The distinguishing characteristics of "nanopass" are said to be:
(1) the intermediate-language grammars are formally specified and
enforced;
(2) each pass needs to contain traversal code only for forms that
undergo meaningful transformation; and
(3) the intermediate code is represented more efficiently as records
IRs implemented using records/structs go back to the 1960s (if not
earlier).
Formally specified IR grammars go back at least to Algol (1958). I
concede that I am not aware of any (non-academic) compiler that
actually has used this approach: AFAIAA, even the Algol compilers
internally were ad hoc. But the *idea* is not new.
I can recall as a student in the late 80's reading papers about
language translation and compiler implementation using Prolog
[relevant to this in the sense of being declarative programming]. I
don't have cites available, but I was spending a lot of my library
time reading CACM and IEEE ToPL so it probably was in one of those.
I'm not sure what #2 actually refers to. I may be (probably am)
missing something, but it would seem obvious to me that one does not
write a whole lot of unnecessary code.
The article talks about deficiencies noted with various support tools
and drivers that were provided to aid students in implementing
so-called "micropass" compilers, but who wrote those tools? Not the
students. If there was much superfluous code being used or generated,
well whose fault was that?
Aside: I certainly could see it being a reaction to working with Java
where tree walking code has to be contorted to fit into the stupid
multiple dispatch and vistor patterns.
YMMV, (and it will)
George
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
