From: | Joachim Durchholz <joachim.durchholz@web.de> |
Newsgroups: | comp.compilers |
Date: | 17 Jul 2003 00:32:41 -0400 |
Organization: | Compilers Central |
References: | 03-07-042 03-07-093 |
Keywords: | analysis |
Posted-Date: | 17 Jul 2003 00:32:41 EDT |
Bob Sheff wrote:
> A more difficult case ( 2 pass or backward looking) is when the <target> is
> ahead of the GOTO, but the procedure is similar: bracket the group, and
> convert the <if> to a <DO>..<While> (or a <repeat>...<until> logically
> inverted <expression>).
Things get somewhat more complicated if you have interleaved GOTOs, such
as in
label 1:
...
label 2:
...
if <something> then goto label 1
...
if <something> then goto label 2
This all *can* be resolved, but it's not so trivial as it would look at
first glance.
The one technique that will *always* work uses boolean helper variables
(in the following, indicated by a h_ prefix):
1. Wrap the entire routine into a
while not h_done do ... end
loop.
2. For every "goto" statement, introduce a local variable.
3. Wrap each basic block into an
if h_block_N then ... end
statement.
Generate a h_block_N variable for block N.
(Also wrap the first basic block before the first label, and the last
basic block after the last label).
4. Replace every goto statement with assignments to the h_* variables so
that the rest of the loop will do nothing, and the next iteration of the
loop will select the appropriate block.
(Caveat: this is just a rough sketch, I haven't filled in all the details.)
If the goal is to get a better understanding of the code, this technique
will be quite unhelpful.
If the goal is to transform the code into a language that doesn't have
gotos (and never touch the generated code again), then this "just works".
Regards,
Jo
Return to the
comp.compilers page.
Search the
comp.compilers archives again.