How to GOTO
Marcel Hendrix
Because there is no program documentation I have to keep as close
as possible to original, so that I can run the Forth code to see what
the Fortran code intends to do. (In a later state I may select to
'improve' the program.)
The problem is that the Fortran programmer used GOTO for nearly
everything. This means that I have need for a Forth GOTO, at least
temporarily. I checked Wil Baden's code http://home.earthlink.net/~neilbawd/goto.txt,
but it does too much and even redefines the standard control constructs.
My own iForth libraries have a GOTO, but it is geared toward FSM's and
doesn't support alphanumeric labels.
Any suggestions?
One of the easier pieces of code that I translated with iForth's GOTOs is
shown below. The number of labels is predefined with u STATES (creates a
table of addresses). The "u ||" text defines a label and starts a :NONAME
definition. If a definition for label x is delimited by ";;", this is
equivalent to "x 1+ GOTO ;". It follows that the labels should be in
strict numeric order. Of course, STATES can not be nested.
The word CALL allows to EXECUTE a numeric label.
Remember that a GOTO can reference a label not yet defined.
-marcel
= -------------------- =
0e FVALUE hsup PRIVATE
0e FVALUE hinf PRIVATE
0e FVALUE hm PRIVATE
0e FVALUE hpr PRIVATE
0e FVALUE x PRIVATE
0 VALUE kk PRIVATE
8 STATES
0 || kr 1 > IF 1 GOTO ENDIF
instrm kr1 >= IF 2 GOTO ENDIF
CLEAR hx 7 GOTO ;
1 || kr 7 < IF 2 GOTO ENDIF
hbmax{{ kr 1- instrm 1- }} DF@ TO hsup
hbmin{{ kr 1- instrm 1- }} DF@ TO hinf
3 GOTO ;
2 || hamax{{ kr 1- instrm 1- }} DF@ TO hsup
hamin{{ kr 1- instrm 1- }} DF@ TO hinf ;;
3 || hsup hinf F- TO hm
h{{ kr 1- instrm 1- }} DF@ TO hpr
CLEAR kk
hpr F0< IF 5 GOTO ENDIF ;;
4 || 1 FCHOOSE TO x
n 1 > IF 6 GOTO ENDIF ;;
5 || hm x F* hinf F+ TO hx
7 GOTO ;
6 || 2 CHOOSE IF 1e x FSQRT F- hm F* hpr F+
ELSE 1e x FSQRT F- hm F* hpr revF-
ENDIF TO hx
hx hinf F>= hx hsup F<= AND IF 7 GOTO ENDIF
kk kt2 >= IF 5 GOTO ENDIF
1 +TO kk
4 GOTO ;
7 || hx h{{ kr 1- instrm 1- }} DF! ;
: PART6 ( -- )
0 CALL
kt1 IF CR ." PART 6, k = " kk DEC. ." x = " x F. ." hx = " hx F. ENDIF ;
William James
Marcel Hendrix wrote:
> I am currently rewriting a Fortran II program for the IBM-7090.
> Because there is no program documentation I have to keep as close
> as possible to original, so that I can run the Forth code to see what
> the Fortran code intends to do. (In a later state I may select to
> 'improve' the program.)
>
> The problem is that the Fortran programmer used GOTO for nearly
> everything. This means that I have need for a Forth GOTO, at least
> temporarily. I checked Wil Baden's code http://home.earthlink.net/~neilbawd/goto.txt,
> but it does too much and even redefines the standard control constructs.
Perhaps something like
'a' label c!
begin
case label c@
'a' of
foo
bar? if 'e' label c! else 'b' label c! then
endof
'b' of
toil_and_roil
'd' label c!
endof
'c' of
endof
'd' of
endof
'e' of
endof
'f' of
endof
endcase
again
foxchip
> Any suggestions?
tail-recursion
colon definitions normally compile a call
; following a call turns it into a jump to label
goto label of normal colon definition label
is the tradition of goto being one character
a too simple to work solution here
due to other unstated complications?
Best Wishes
Josh Grams
> I am currently rewriting a Fortran II program for the IBM-7090...
> [and] I have need for a Forth GOTO, at least temporarily.
This caught my interest, so I'm going to respond even though I'm not
sure I have anything helpful to suggest...
>I checked Wil Baden's code http://home.earthlink.net/~neilbawd/goto.txt,
>but it does too much and even redefines the standard control
>constructs.
I'm not clear why that's a problem. Has it proven to be too slow? Or
is it that you need GOTOs that can branch to a label inside a separate
colon definition?
> Any suggestions?
>
> Remember that a GOTO can reference a label not yet defined.
I can't think of anything totally portable. But if you have access to
words for creating branches and modifying their targets, then it seems
like a relatively simple problem.
For instance, assuming AHEAD and THEN allow you to branch between
words
(some Forths check and restrict them to the current colon definition),
and you could define:
\ Translate an XT to a DEST (which can be used with AGAIN, UNTIL,
etc.)
: >cfa ( xt -- dest ) ... ;
Then you could define a lookup table for forward references:
\ Save a reference to an undefined label for later resolution
( NAME points to a counted string )
( ORIG is a forward branch which needs to be resolved )
: forward-label ( name orig -- ) ... ;
\ Return any forward references to NAME (a counted string)
: references ( name -- orig-0 ... orig-n n ) ... ;
And define goto as follows, and modify colon to resolve any
outstanding
GOTOs to the new name.
: goto ( "name" -- )
bl word find if
>cfa postpone again
else
there dup postpone again forward-label
then ; immediate
: :
>in @ >r :
r> >in ! bl word references 0 ?do
latest >cfa postpone then
loop ;
You could presumably define LABEL ( "name" -- ) similarly to colon if
you need labels inside colon definitions. But again, I'm not clear on
the exact parameters of your problem, or where you need the solution
to
run, so this sort of thing may not work for you at all...
--Josh
Jenny Brien
> I am currently rewriting a Fortran II program for the IBM-7090.
> Because there is no program documentation I have to keep as close
> as possible to original, so that I can run the Forth code to see what
> the Fortran code intends to do. (In a later state I may select to
> 'improve' the program.)
>
> The problem is that the Fortran programmer used GOTO for nearly
> everything. This means that I have need for a Forth GOTO, at least
> temporarily. I checked Wil Baden's code
> http://home.earthlink.net/~neilbawd/goto.txt,
> but it does too much and even redefines the standard control constructs.
>
> My own iForth libraries have a GOTO, but it is geared toward FSM's and
> doesn't support alphanumeric labels.
>
> Any suggestions?
Assuming your control stack is two items on the data stack:
: TARGET \ -- predeclare a label for a backward GOTO
CREATE 0 , 0 ,
DOES> >R POSTPONE BEGIN R> 2! ; IMMEDIATE
: <GOTO \ ++ compile backward branch to named target
' 2@ POSTPONE AGAIN ; IMMEDIATE
: GOTOS \ n -- ; predeclare a label allowing n forward branches
CREATE 0 , 2 CELLS * ALLOT
DOES> DUP >R DUP CELL+ SWAP @ DO \ resolve branches
DUP 2@ POSTPONE THEN 2 CELLS + LOOP DROP
0 R> ! \ reset count
: GOTO \ ++ compile branch to named target
' >R POSTPONE AGAIN
R@ DUP @ 2* 1+ CELLS + 2!
1 R> +! ;
>
> One of the easier pieces of code that I translated with iForth's GOTOs is
> shown below. The number of labels is predefined with u STATES (creates a
> table of addresses). The "u ||" text defines a label and starts a :NONAME
> definition. If a definition for label x is delimited by ";;", this is
> equivalent to "x 1+ GOTO ;". It follows that the labels should be in
> strict numeric order. Of course, STATES can not be nested.
> The word CALL allows to EXECUTE a numeric label.
>
> Remember that a GOTO can reference a label not yet defined.
>
So I declare them first! (Labels can be reused)
1 GOTOS ONE:
2 GOTOS TWO:
1 GOTOS THREE:
TARGET FOUR<:
1 GOTOS FIVE:
TARGET FIVE<:
1 GOTOS SIX:
1 GOTOS SEVEN:
: ZERO kr 1 > IF GOTO ONE: ENDIF
instrm kr1 >= IF GOTO TWO: ENDIF
CLEAR hx GOTO SEVEN:
ONE: kr 7 < IF GOTO TWO: ENDIF
hbmax{{ kr 1- instrm 1- }} DF@ TO hsup
hbmin{{ kr 1- instrm 1- }} DF@ TO hinf
GOTO THREE:
TWO: hamax{{ kr 1- instrm 1- }} DF@ TO hsup
hamin{{ kr 1- instrm 1- }} DF@ TO hinf
THREE: hsup hinf F- TO hm
h{{ kr 1- instrm 1- }} DF@ TO hpr
CLEAR kk
hpr F0< IF GOTO FIVE: ENDIF
<FOUR: 1 FCHOOSE TO x
n 1 > IF GOTO SIX: ENDIF
FIVE:
<FIVE: hm x F* hinf F+ TO hx
GOTO SEVEN:
SIX: 2 CHOOSE IF 1e x FSQRT F- hm F* hpr F+
ELSE 1e x FSQRT F- hm F* hpr revF-
ENDIF TO hx
hx hinf F>= hx hsup F<= AND IF GOTO SEVEN: ENDIF
kk kt2 >= IF <GOTO <FIVE: ENDIF
1 +TO kk
<GOTO <FOUR:
SEVEN: hx h{{ kr 1- instrm 1- }} DF! ;
: PART6 ( -- )
ZERO
Frank
My Recommendation is simply to rewrite the code without the use of the
goto's. The use of the GoTo is a nightmare. In the past I have told
all of my students to never use a GoTo, in fact I penalized them if
they did, regardless of the language we were working in. Just rethink
the flow. It is easier than you think.
Frank
John Passaniti
His goal is apparently to start with a direct Forth translation of the
Fortran code and then later refactor to something better. This is
common practice when you want to ensure your translation is equivalent
before you start improving it.
I don't know who or what you teach, but isn't a better position to take
that the student may use *whatever* techniques they want, but that they
have to be able to justify their choices?
Instead of penalizing a student for using a facility that the language
itself provides (and that is in the underlying processor's instruction
set), how about you instead take that student's code, rework it without
GOTOs yourself, and ask the student if they believe your version is
better. If the student agrees, then take some points off. But if the
student's answer is no (and they can defend their position), then you
don't penalize them: you instead learn from your students. A little
role reversal never hurt anyone.
Anton Ertl
>I am currently rewriting a Fortran II program for the IBM-7090.
>Because there is no program documentation I have to keep as close
>as possible to original, so that I can run the Forth code to see what
>the Fortran code intends to do. (In a later state I may select to
>'improve' the program.)
>
>The problem is that the Fortran programmer used GOTO for nearly
>everything. This means that I have need for a Forth GOTO, at least
>temporarily. I checked Wil Baden's code http://home.earthlink.net/~neilbawd/goto.txt,
>but it does too much and even redefines the standard control constructs.
It has to, because the labels and gotos throw additional origs and
dests on the control flow stack; if it did not redefine the standard
control structures, they would not work in combination with labels and
gotos. And since he has no conditional goto, he has to mix standard
control constructs and gotos. Also, once you start cleaning up, you
will want to use more elaborate Forth control structures, not just IF
GOTO ... ENDIF.
>My own iForth libraries have a GOTO, but it is geared toward FSM's and
>doesn't support alphanumeric labels.
Does Fortran II support alphanumeric labels? I don't think so.
>Any suggestions?
If you are doing it non-portably, you can do it like an assembler and
recording all the label addresses and all the gotos in tables, and
resolve them in the end.
If you want standard code, I would do it like Wil Baden, so I would
just use his code.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2007: http://www.complang.tuwien.ac.at/anton/euroforth2007/
Marcel Hendrix
> Marcel Hendrix wrote:
>> I am currently rewriting a Fortran II program for the IBM-7090.
[..]
>> This means that I have need for a Forth GOTO, at least
>> temporarily.
[..]
> Perhaps something like
> 'a' label c!
> begin
> case label c@
> 'a' of
> foo
> bar? if 'e' label c! else 'b' label c! then
> endof
[..]
> endcase
> again
Interesting idea! However, AFAICS, common GOTO code would need a test
after each label assignment, making the code even more impenetrable:
8 STATES
0 || kr 1 > IF 1 GOTO ENDIF
instrm kr1 >= IF 2 GOTO ENDIF
CLEAR hx 7 GOTO ;
1 || ...
2 || ...
7 || ...
'a' label c!
begin
case label c@
'a' of kr 1 > IF 'd' label c! ENDIF endof
'b' of instrm kr1 >= IF 'e' label c! ELSE 'c' label c! ENDIF endof
'c' of CLEAR hx 'f' label c! endof
'd' of ... endof
'e' of ... endof
'f' of ... endof
-marcel
William James
That was just a shot in the dark. This reminds me of the old
days when I used to translate BASIC programs with line-numbers.
My first step was to take a pen and underline every line-number
that was actually gone-to.
Jenny Brien
wrote:
>>
> So I declare them first! (Labels can be reused)
>
> 1 GOTOS ONE:
> 2 GOTOS TWO:
> 1 GOTOS THREE:
>
My mistake:
TARGET <FOUR:
TARGET <FIVE:
3 GOTOS SEVEN:
I was thinking of possible factorings at the same time. :[
A less error-prone syntax and nearer to the orginal Fortran would combine
both forward and backward jumps:
: LABEL CREATE 0, 0, \ space for dest
0, 10 CELLS ALLOT \ counted array for origs - use
linked list?
DOES>
>R POSTPONE BEGIN R@ 2! \ store dest
R@ 2 CELLS + DUP CELL+ SWAP @ DO \ resolve any branches
DUP 2@ POSTPONE THEN 2 CELLS + LOOP DROP
0 R> ! \ reset count
; IMMEDIATE
: LABELS 0 ?DO label LOOP ;
: GOTO \ compile forward or backward jump
' >BODY DUP @ IF - no dest, must be a forward jump
2 CELLS + >R POSTPONE AHEAD
R@ DUP @ 2* 1+ CELLS + 2! \ store orig
1 R> +!
ELSE
2@ POSTPONE AGAIN THEN ; IMMEDIATE
Jeff M.
> I am currently rewriting a Fortran II program for the IBM-7090.
> Because there is no program documentation I have to keep as close
>
> The problem is that the Fortran programmer used GOTO for nearly
>
> Any suggestions?
Presumably, looking at the Fortran code, you do know what all the
labels are ahead of time. Creating a jump table to be filled in at a
later time would seem trivial to do. Almost like a glorified or
embedded DEFER/IS pair.
\ start of jump table
DEFERRED-LABEL a
DEFERRED-LABEL b
\ test suite
: test ( -- )
GOTO b
LABEL a
." Cya!" cr
EXIT
LABEL b
." Hello!" cr
GOTO a
;
Now it's just the definitions of those 3 words: DEFERRED-LABEL, GOTO,
and LABEL. DEFERRED-LABEL is just a CELL with an address to be later
filled in by LABEL. GOTO is just a word to set the IP to whatever is
in that CELL.
I may be missing something, but that doesn't strike me as particularly
difficult to do. Of course, the above is making 2 big assumptions: you
actually are okay with pre-declaring the label name and that labels/
gotos aren't jumping across words or out of DO/LOOP loops.
If you need the gotos to jump across words or out of DO/LOOP loops,
then the problem gets more difficult (and perhaps that's the info you
are looking for?). :)
Jeff M.
Marcel Hendrix
> On Dec 4, 4:25 am, m...@iae.nl (Marcel Hendrix) wrote:
[..]
>> The problem is that the Fortran programmer used GOTO for nearly
>> everything. This means that I have need for a Forth GOTO, [...]
[..]
> Now it's just the definitions of those 3 words: DEFERRED-LABEL, GOTO,
> and LABEL. DEFERRED-LABEL is just a CELL with an address to be later
> filled in by LABEL. GOTO is just a word to set the IP to whatever is
> in that CELL.
> I may be missing something, but that doesn't strike me as particularly
> difficult to do. Of course, the above is making 2 big assumptions: you
> actually are okay with pre-declaring the label name and that labels/
> gotos aren't jumping across words or out of DO/LOOP loops.
With GOTO's you tend to have a solid block of code, so jumping out of a
word to inside another one is not necessary. To jump out of a DO LOOP is
needed, but it is OK to write IF UNLOOP x GOTO ENDIF .
Note that with an optimizing Forth, it is not a good idea to secretly
mark an arbitrary address in a word and later jump to it from just any
location. Using BEGIN for this spot should work, but then you must make
sure this BEGIN does not interfere with existing flow-of-control words :-)
Predeclaring labels by name is not nice when you have 50 or more labels.
If labels are numeric it is easy; just allocate 50 cells.
The downside there is that you are not allowed to leave holes when
something like my ";;" construct is wanted (so maybe a better solution
is just to fix ;; :-)
Hmm, numeric parsing labels might be okay with an extra word RESOLVE-GOTOS,
and having an assembler-like linked list of labels. Alphanumeric labels
could be done by ALLOCATEing label names and let RESOLVE-GOTOS do a string
match and FREE. The resolve step could also fill in the actual address so
that the table is only temporarily needed (thus could be reclaimed, and
therefore could be hidden).
> If you need the gotos to jump across words or out of DO/LOOP loops,
> then the problem gets more difficult (and perhaps that's the info you
> are looking for?). :)
I was looking for a prefab, more elegant and lighter-weight GOTO than
Wil Baden's kitchensink or my own clunky GOTO. I should be pleasantly
surprised that such words are obviously far and far removed from Forth
daily practice.
Thanks to all of you posters who gave this idea a whirl!
-marcel
Stephen Pelc
>Any suggestions?
This is the same problem as local labels in assemblers. We must have
fixed this in our C to Forth translater at
http://www.mpeforth.com/arena/c2forth110.zip
Stephen
--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
Jenny Brien
> Note that with an optimizing Forth, it is not a good idea to secretly
> mark an arbitrary address in a word and later jump to it from just any
> location. Using BEGIN for this spot should work, but then you must make
> sure this BEGIN does not interfere with existing flow-of-control words
> :-)
>
Do you need to use an optimising Forth? I don't have enough experience of
optimising to know how it would affect my scheme of fiddling with the
control stack. As it stands it allows jumping from the middle of one
definition to the middle of another, but that should not be needed - the
entire block can be in one big definition (no need for ;;).
> Predeclaring labels by name is not nice when you have 50 or more labels.
> If labels are numeric it is easy; just allocate 50 cells.
> The downside there is that you are not allowed to leave holes when
> something like my ";;" construct is wanted (so maybe a better solution
> is just to fix ;; :-)
>
> Hmm, numeric parsing labels might be okay with an extra word
> RESOLVE-GOTOS,
> and having an assembler-like linked list of labels. Alphanumeric labels
> could be done by ALLOCATEing label names and let RESOLVE-GOTOS do a
> string
> match and FREE. The resolve step could also fill in the actual address so
> that the table is only temporarily needed (thus could be reclaimed, and
> therefore could be hidden).
>
>
How about this?
Have two lists, one for labels and one for lists of unresolved GOTOs
(because one label may resolve several).
GOTO /name/ IMMEDIATE
search labels for /name/
found? IF
fetch-dest POSTPONE AGAIN \ resolve a backward jump
ELSE POSTPONE AHEAD \ C: -- orig ; set up a forward jump
search unresolved for /name/
found? 0= IF create-unresolved-entry THEN link-orig \ C: -- ;
LABEL /name/ IMMEDIATE
search unresolved for /name/
found? IF
BEGIN got-orig? WHILE \ C: -- orig ;
POSTPONE THEN REPEAT \ C: -- ; resolve forward jumps
remove-entry THEN
POSTPONE BEGIN \ C: -- dest ; set up for backward jumps
create-label-entry store-dest \ C: -- ;
CHECK \ -- ; used at the end of a code block
count-unresolved-entries \ -- n ;
IF issue-warning THEN \ there's an unmatched GOTO
empty-lists
Marcel Hendrix
> How about this?
[..]
There is a "THEN" missing from your pseudoForth.
Regardless, AFAICS your scheme does not allow to jump out of
IF .... THEN or any other control-flow-construct. That is
simply too restrictive for my purpose.
-marcel
astrobe
> Fortran code and then later refactor to something better. This is
> common practice when you want to ensure your translation is equivalent
> before you start improving it.
>
Another common practice is to write a set of tests for the existing
program, then to write the new program, and finally to run the tests
against the new program in order to make sure both are acting the same
way.
IMHO, raw translation then refactoring has serious drawbacks:
- translation problems (OP)
- the refactoring work is harder, because not only you inherit the
defects of the original program, you also add the defects of the
translation.
Of course the OP may get more quickly a working program, but in the
end, it costs more.
> I don't know who or what you teach,
Well, if he has to talk about GOTOs in his teaching, I guess he is
teaching ski jump to cats.
> but isn't a better position to take
> that the student may use *whatever* techniques they want, but that they
> have to be able to justify their choices?
>
> Instead of penalizing a student for using a facility that the language
> itself provides (and that is in the underlying processor's instruction
> set), how about you instead take that student's code, rework it without
> GOTOs yourself, and ask the student if they believe your version is
> better. If the student agrees, then take some points off. But if the
> student's answer is no (and they can defend their position), then you
> don't penalize them: you instead learn from your students. A little
> role reversal never hurt anyone.
I'm not a teacher, but I guess it would be a lot of time wasted on a
minor topic. A little explaination of why "goto is evil except on
febuary 29th" is enough.
Amicalement,
Astrobe
John Passaniti
>> I don't know who or what you teach,
>
> Well, if he has to talk about GOTOs in his teaching, I guess he is
> teaching ski jump to cats.
Cute. But my implied question on who is if he is teaching young kids, a
college course, a seminar for developers, or some other group. Knowing
that would make a difference as to presentation and goals. My implied
question on what is taught is about if this is a basic programming
course, an advanced programming course, teaching specific techniques,
etc. That again puts a context on the discussion.
>> but isn't a better position to take
>> that the student may use *whatever* techniques they want, but that they
>> have to be able to justify their choices?
>>
>> Instead of penalizing a student for using a facility that the language
>> itself provides (and that is in the underlying processor's instruction
>> set), how about you instead take that student's code, rework it without
>> GOTOs yourself, and ask the student if they believe your version is
>> better. If the student agrees, then take some points off. But if the
>> student's answer is no (and they can defend their position), then you
>> don't penalize them: you instead learn from your students. A little
>> role reversal never hurt anyone.
>
> I'm not a teacher, but I guess it would be a lot of time wasted on a
> minor topic. A little explaination of why "goto is evil except on
> febuary 29th" is enough.
But that's the point-- as a teacher, he is disallowing the use of goto
and penalizing students if they use it. That to me isn't teaching--
that's relaying and enforcing dogma without allowing questioning. And
that is what I objected to.
Jenny Brien
> "Jenny Brien" <jenn...@figuk.plus.com> wrote Re: How to GOTO
>
>> How about this?
>
> [..]
>
> There is a "THEN" missing from your pseudoForth.
Right, it should be:
GOTO /name/ IMMEDIATE
search labels for /name/
found? IF
fetch-dest POSTPONE AGAIN \ resolve a backward jump
ELSE POSTPONE AHEAD \ C: -- orig ; set up a forward jump
search unresolved for /name/
found? 0= IF create-unresolved-entry THEN link-orig \ C: -- ;
THEN
>
> Regardless, AFAICS your scheme does not allow to jump out of
> IF .... THEN or any other control-flow-construct. That is
> simply too restrictive for my purpose.
>
Not so. The new words have no effect on the existing control structures,
since they have no net effect on the control stack.
LINK-ORIG removes the orig left by AHEAD in GOTO and makes it available
only to the GET-ORIG in a following label with the same name. STORE-DEST
removes the dest left by BEGIN in LABEL so that it can only be read by the
FETCH-DEST in a following GOTO with the same name.
This is a development of the simple single GOTO (where CS-cell == 2 data
stack cells)
2VARIABLE CS
: >: cs 2! ; IMMEDIATE
: :< cs 2@ ; IMMEDIATE
Examples:
BEGIN BEGIN ... IF >: ... AGAIN AGAIN :< THEN
: FOO ." a" BEGIN >: ." b" ;
: BAR ." c" :< AGAIN ;
foo a b ok
bar c b ok