Re: Code Generation

[Jeffrey A Law <law at hurl dot cygnus dot com>]

  In message <19990103074421.28824.qmail@field.medicine.adelaide.edu.au>you wri
te:

  > I wanted to float the idea of opening up the back-end to people like me,
  > who really +don't+ want to tinker with compilers, or distribute compilers,
  > but who need access to some of the metadata in the compiler.  I think the
  > best way to do it, once and for all, is to define an interface for the
  > backend transfer of the metadata, and I think the least intrusive way is
  > as I've described.
I've been involved in a variety of these kinds of projects in the past; 
purify-like memory checkers,  generation of runtime data to drive function
reordering, instrumentation of code to provide minimal branch histories, and
other things.

In my experience you are best off writing the instrumentation code directly
into the code generator in the compiler.  You get a lot of target independence
that way.  You can also avoid a lot of instrumentation overhead by allowing
the optimizer to chomp on the instrumented code.

The amount of compiler internals you need to learn to emit macro-ized code
are going to be about the same as you would if you hooked directly it the
code generator.  And by hooking into the code generator, you instrumentation
support will be useful by other people on a much wider variety of platforms.

I'm also strongly opposed to emitting any kind of macro-ized assembler by the
the compiler.  My experiences with macro-ized assembler code have been less
than pleasant and we're working towards less reliance of macro-ized assembler
code in the one remaining port which relies heavily on it (mips).


jeff