From: | Paul Robinson <postmaster@paul.washington.dc.us> |
Newsgroups: | comp.compilers |
Date: | 15 Jul 2003 23:42:17 -0400 |
Organization: | Elusive-Butterfly.net |
References: | 03-07-042 |
Keywords: | translator |
Posted-Date: | 15 Jul 2003 23:42:16 EDT |
Dana Freer wrote:
> I am not a compiler writer but have the task of writing a tranlslator to
> convert from a language which allows GOTO, GOSUB, RETURN into a language
> (like VbScript) which does not alllow GOTO etc. Is this impossible? Will
> human intervention always be required?
Every form of looping construct can be simulated by a test and a goto. In
fact, at the assembly level, that's exactly what happens.
But your question is the exact opposite. The answer to your question is
Yes, if the goto is a downward (in code) such as this example, which is from
a fictional language which is a combination of BASIC, Pascal and FORTRAN:
10020 D75X := 154
10036 IF M < 72 AND K>5 GOTO 23034
10071 W9 := ABS(NQ)
..
..
23000 GOTO 23035 .
23034 W9:= ABS(QN)
23035 CALL EAX4(W9)
You can change that into:
10036 FLAG23034 := FALSE
FLAG23034 := M <72 AND K>5
IF NOT FLAG23034 THEN
ELSE
23034 W9 = ABS(QN)
ENDIF
23035 CALL EAX4(W9)
But if it's possible to be that clean they might not have used gotos in the
first place. On the other hand, maybe it isn't.
In some cases the code had to be done using gotos because the constructs
such as 'gotoless if' and 'while' were unavailable. But if you have a
program where the gotos jump all over the place, you're not going to be able
to automatically make the translation. It will still need to be checked to
make sure that the translation of the goto into something else is correct.
Generally the only way I see it is to implement some form of a flag with a
boolean test, that in one case the test executes a certain block of code,
and in the other case it does not. This can substitute for a goto. But if
you have to jump into the middle of that test, you'll need to break down the
test into additional tests in order to allow entry into a specific point..
I believe that you cannot eliminate all cases to automatic translation.
Give me about 20 minutes and I'll design a program that CANNOT be
automatically translated to eliminate GOTOS, because it will jump around so
much you could not reprogram for them, because you can't tell when the jump
is going to occur or isn't. You can work around it, but I strongly suspect
in the end some manual analysis will be required.
I think this may have been the reason Wirth decided to include GOTO in
Pascal, because there are certain very good constructs where it works better
to allow a goto than to fight it by using a flag and an IF. And there may
be some particular algorithms where it cannot be done though the usual
looping technologies without a much less efficient and much harder to
understand and implement method.
There are, however, some saving points.
Remember, any piece of code which is preceded by a goto statement to prevent
entry except after that goto statement, at the beginning of the routine, by
a goto from somewhere else to there, and where that code has only one exit,
either by an unconditional goto elsewhere, or a return (from a subroutine
call into the whole routine) or whatever, is a straight-line block of code
that can itself be converted to a sub that can be called as opposed to using
a "goto in - goto out" sequence. You could break the pieces that are
definitely straight-line blocks of code that have no intermediate entry
points into subroutines, move them to a separate area, then have the test
determine which of those to call. That might help.
--
Paul Robinson "Above all else... We shall go on..."
"...And continue!"
"If the lessons of history teach us anything it is
that nobody learns the lessons that history teaches us."
Return to the
comp.compilers page.
Search the
comp.compilers archives again.