Seeing IR in code that generates it

Paul_Long@ortel.org (Paul Long)
Fri, 29 Jul 1994 20:56:00 GMT

          From comp.compilers

Related articles
Seeing IR in code that generates it Paul_Long@ortel.org (1994-07-29)
| List of all articles for this month |

Newsgroups: comp.compilers
From: Paul_Long@ortel.org (Paul Long)
Keywords: optimize
Organization: Oregon Telcom
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
read, either.


Paul_Long@ortel.org
--


Post a followup to this message

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