|Seeing IR in code that generates it Paul_Long@ortel.org (1994-07-29)|
|From:||Paul_Long@ortel.org (Paul Long)|
|Date:||Fri, 29 Jul 1994 20:56:00 GMT|
Geez, it's awful quiet around here!
Here's something that's been bothering me. Let's see if you have any
suggestions. A compiler I'm working on has an Intermediate Representation
that basically consists of a list of parse trees, but now that I think
about it, the form probably doesn't matter for what I'm going to ask.
Does anyone have a good solution for making it easy from reading the
compiler code itself what IR it generates?
I try to spatially isolate and consolidate the construction of a node, for
example, an addition node. I also have "worker" functions that construct
particular node types. The problem is that once I have worked out and
implemented how the front end will translate a higher-level construct,
such as a case statement, it's not obvious from looking at the code what
kind of IR it generates. I think I write good, modular code (hey, but
then doesn't everybody think this about their own code?), and I document
how source-level constructs are translated in nearby comments, but it
seems like there must be a better way. I suppose I could come up with a
grand table-driven scheme, but I don't think that would be very easy to
Return to the
Search the comp.compilers archives again.