Re: STEP compiler generator

gah4 <gah4@u.washington.edu>
Fri, 17 Jun 2022 15:13:33 -0700 (PDT)

          From comp.compilers

Related articles
STEP compiler generator gah4@u.washington.edu (gah4) (2022-06-14)
Re: STEP compiler generator gah4@u.washington.edu (gah4) (2022-06-17)
Re: STEP compiler generator christopher.f.clark@compiler-resources.com (Christopher F Clark) (2022-06-22)
Re: STEP compiler generator gah4@u.washington.edu (gah4) (2022-06-21)
Re: STEP compiler generator gah4@u.washington.edu (gah4) (2022-06-21)
| List of all articles for this month |

From: gah4 <gah4@u.washington.edu>
Newsgroups: comp.compilers
Date: Fri, 17 Jun 2022 15:13:33 -0700 (PDT)
Organization: Compilers Central
References: 22-06-045
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="40320"; mail-complaints-to="abuse@iecc.com"
Keywords: tools, history, comment
Posted-Date: 17 Jun 2022 23:20:17 EDT
In-Reply-To: 22-06-045

(I wrote)


> http://www.bitsavers.org/pdf/stanford/slac/The_STEP_Processor.pdf


I wasn't expecting a lot of discussion, but I thought someone might
say something.


I was thinking, though, about how it might be done today.


Taking the core parser generator from Bison, that is without the I/O
routines so it could be included in another program for a start.


Then a new program to use the generated parsing table, similar to the
way STEP interprets its generated parser.


A new language to write actions instead of generating C code.
Bison parsers depend on the output being processed by a C compiler.
I suspect that most Bison users use only a small subset of C in their
actions, so one could define a subset, or a new language for writing
actions. Either one would allow for a simple compiler and the ability
to interpret its output.


One thing about STEP, is that as each rule and replacement procedure
is compiled, is linked with the running system, and is immediately
available for use. That is unlike the usual use of Bison, where the
whole thing is compiled at the end.
[Reminds me of IMP72 where you could put new syntax rules in your program
and either make them a macro or call internal routines. It seemed like a
good idea at the time but what it meant was that no two IMP programs were
written in the same language and they tended to be unreadable. -John]


Post a followup to this message

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