Re: Code Generators

Mike Lichak <michael_lichak@powersurfr.com> wrote:


>Here's the problems I always run into. The code can be compiled and
>delivered, as is, to the end-user, about 80% of the time. The rest of
>the time, I have to hand-edit parts of the code.
>
>Once I do that, and find a bug in my code-generator, or add a nifty
>new feature to the code-generator, I have to hand modify or cut and
>pasted that 20% of customized code.


Been there, done that, got *sick* of cutting and pasting (and the
resulting thick-finger induced errors), and added "signposts" to the
*generated* code at the spots that I formerly editted by hand. Each
signpost has a qualified name, something like:


module_x.procedure_y.variable_z.typecheck(x,y,z)


Then, it's simply a matter of putting the text for the generated
language signpost insertions into a "post-compile" header file:


#signpost module_x.procedure_y.variable_z.typecheck(m,n,o) \
"blah(m), blatz(n), blur(o)"


The result would be:


blah(x), blatz(y), blur(z)


The advantage of this is that your second stage compiler can ignore
any undefined signposts (actually, you use a "matches any" signpost
declaration that expands to nothing:


#signpost *(*) /*empty*/


), it's upward compatible, and you need only define the signposts
substitutions that you need, as you need them.


Each time I found a new need for adding hand code to the output, I'd
design a new type of signpost qualification for the appropriate spot,
with the appropriate parameters, add generation of it to my compiler
and definitions to the project-specific header files, and !viola! home
free, with no source language or high-level source code changes.


All old applications compiled without change, and could be enhanced
for the existing (or new) clients at low overhead.


As hinted at above, I supported wildcarding (and other pattern
matching) of the qualifying name in the substitution definitions, and
multiple matches for each signpost were also allowed and substituted
in the order defined, so one could have generic code that should be
applied, for example, to all typecheck sighposts, plus code that was
specific to a single signpost:


#signpost *.typecheck(m,n,o) "braaack(m,o)"


#signpost module_x.procedure_y.variable_z.typecheck(m,n,o) \
"blah(m), blatz(n), blur(o)"


The result:


braaack(x,z)
blah(x), blatz(y), blur(z)


Very helpful for adding entry/exit debug code to all procedures, as a
concrete example.


>The hand-edited parts are usually quite site-specific to fufill a
>contract, and too intense to justify adding them to the
>code-generator. Or all the hacks I've added make it too hard or
>time-consuming to modify at all. Or the growth of the poorly designed
>input syntax catches up to me. And it's nice to be backward compatible
>with early projects that need mods and additions.


The above suggestion encompases them all - no addition to your input
language, and only minor, incremental, transparent enhancements to
your output code generation. All substitutions can be managed on a
job-specific basis.


Requires another compiler pass, of course. I suggest treating it as a
macro processor. One could enhance cpp, for example, or m4 or awk or
perl, instead of implementing from whole cloth, as I did.


If you implement it, all I ask is that you give me credit, as I
invented the technique from raw cloth circa 1984, and would love to
know who's got first claim. It's too ugly to publish, but too handy
to ignore, and in spirit with having your own application-domain
compiler.


--
Kirk Hays
--

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