eq RETURNTO, "10", CONT_10
AFAIK are these "line numbers", why do you want to use strings - but I really don't know (and will for sure not learn) this "language".
Because "line numbers" are Ancient Basic for designating branch destinations in programs (and statement order!). Nowadays they're optional. They're strings because instead of line numbers, labels can be used. So a perfectly valid BASIC program can even mix forms.
10 print "Hello world"
20 gosub mysub
30 end
mysub: print "Goodbye, world"
returnYes, my friend. Continue to use quotes around the word "language" when describing this mess.
Without RETURN x, just plain old GOSUB/RETURN I could let PIR/PASM handle all by itself with no supervision.
Or you handle "normal subs" like that and generate special code for "return x"?
I could, except that it's impossible to tell where exactly the exit point of a "subroutine" (for GOSUB) is in a BASIC program. In fact, all "GOSUB" destinations could use an unconditional branch to all use a common RETURN point. You just return when you stumble across a return. Further analysis of where the "subroutines" are may be impossible with mechanical (or human) analysis at compile time:
5 rem Valid but seriously spaghettified BASIC example.
7 rem Good luck analyzing this at compile time for entry
9 rem and exit points for the "subroutines".
10 print "Hello, world!"
20 for i = 1 to 3
30 gosub 70
40 next
50 end
70 gosub mysub
80 gosub 110
90 return
100 return 30
110 rem alternate entry point
mysub:
print "Hello, galaxy!"
on int(rnd(2)+1) goto 90, 100For this, the "Hello, galaxy" subroutine could be entered at two different points (110, "mysub") and exited at one of two randomly chosen points (90 or 100) at runtime. Furthermore, one of the return points (100) changes the exit point of the subroutine entered at line 70 (either 90 or 100).
Remember, this is the language that inspired Dijkstra to write "Go To Statement Considered Harmful" (http://www.acm.org/classics/oct95/). :)
