>>>>> "CAP" == Clinton A Pierce <[EMAIL PROTECTED]> writes:
CAP> Yes, my friend. Continue to use quotes around the word "language" CAP> 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"? CAP> I could, except that it's impossible to tell where exactly the exit CAP> point of a "subroutine" (for GOSUB) is in a BASIC program. In fact, CAP> all "GOSUB" destinations could use an unconditional branch to all use CAP> a common RETURN point. You just return when you stumble across a CAP> return. Further analysis of where the "subroutines" are may be CAP> impossible with mechanical (or human) analysis at compile time: CAP> 5 rem Valid but seriously spaghettified BASIC example. CAP> 7 rem Good luck analyzing this at compile time for entry CAP> 9 rem and exit points for the "subroutines". CAP> 10 print "Hello, world!" CAP> 20 for i = 1 to 3 CAP> 30 gosub 70 CAP> 40 next CAP> 50 end CAP> 70 gosub mysub CAP> 80 gosub 110 CAP> 90 return CAP> 100 return 30 CAP> 110 rem alternate entry point CAP> mysub: CAP> print "Hello, galaxy!" CAP> on int(rnd(2)+1) goto 90, 100 okay, i am going to jump in and try to drown here. :) why don't you manage your own basic call stack in an array or PerlArray or something? trying to map that mess of call/return poo onto a proper compiler with register allocation is going to lose us the services of leo while he recuperates at the hospital for homicidal BASIC coders. you will just have to bite the bullet and emulate your own virtual engine over parrot and not try to map BASIC directly to it. so code a VM with BASIC flow control. you can probably do something odd like make each BASIC statement into a parrot sub. then just compile your basic into a simple flow control IL that just calls parrot subs. the subs all have access to your need globals (with the obvious find_global/set_global :) a primary global now is the BASIC VM PC. so your code gen is much easier too. each statement is codegenned and you keep their label or sequence numbers in your flow tree and they map to a parrot sub address (that you generate as you codegen). later to execute you just scan your own flow tree (that is the basic interpreter engine), call each parrot sub (BASIC statement)in turn and let parrot to the real work in each statement. BASIC calls and returns are handled with munging the global BASIC PC and the global stack. feel free to tell me this is total cocky-pop. :) uri -- Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
