Is it possible to Gosub to a variable?

[Bill Franke]

I'd like to GOSUB to a variable if this is possible. I've played around with STRPTR but without success. Any help would be appreciated.

DIM point AS DWORD
XX$=Air_Injector

point = STRPTR(XX$)
GOSUB DWORD point


Air_Injector:
'code
RETURN

[Marco Pontello]

To a (numeric) variable, yes; to a string, no (not directly).
This works:

FUNCTION PBMAIN

  DIM p AS LONG
  
  p = CODEPTR(MyLabel)
  GOSUB DWORD p
  
  WAITKEY$
  EXIT FUNCTION       
       
MyLabel:
  PRINT "MyLabel reached!"
  RETURN       
       
END FUNCTION

If you want to use a string to identify a target, just organize whatever kind of list you prefer to associate a string to a number.

Bye!

[Michael Mattias]

 ON var GOSUB x, y, z...

???

Let'ts enance that a little bit...
Original code:

XX$=Air_Injector
point = STRPTR(XX$)
GOSUB DWORD point

How about

   ON SWITCH (XX$ = "Air_Injector", 1, _ 
                     XX$="Steam_shovel", 2, _
                     XX$ = "Dump_truck", 3) _ 
         GOSUB air_injector, steam_shovel, dump_truck

Kind of the long way, but hey, it looks pretty cool.

[John Petty]

Simple answer is no
Gosub, Function, Sub must point to actual code.
You can gosub to code as the result of a test on a variable (and the address of the code can be stored in a dword) but programs can only run code. If your sting contained binary machine code but not text

[Don Schullian]

Bill,

Have a look at ON GOSUB. It allows you to use it with "line numbers".

[Mel Bishop]

Keeping in mind that the subroutine must be located within the confines of the SUB/FUNCTION that is calling it.

You cannot GOSUB outside the boundaries of SUB/FUNCTION <-> END SUB/FUNCTION.

That little detail caused me a lot of headscratching when I transitioned from PB/DOS to CC.

[Chris Holbrook]

Given that you can get a pointer to code, I can't see why you should not be able to copy code into a string and execute it. However, there is a constraint on GOSUB that the label should be within the current block, I'm not sure how, or if, the generated code enforces this if you GOSUB to a CODEPTR. Why not give it a try?

[Michael Mattias]

Given that you can get a pointer to code, I can't see why you should not be able to copy code into a string and execute it.

????

If you can get a pointer to the code, you can CALL it, GOTO it or GOSUB to it using the DWORD option provided by the compiler for all three verbs. Why bother getting its length, copying it into a string after allocating virtual memory with execute permissions and all that stuff?

[Chris Holbrook]

Why bother...?

quite.

[Ronald Fuerst]

Air_Injector is a label

I was able to get this code working;


XX$= STR$ ( CODEPTR (Air_Injector) )
point = VAL(XX$)
GOSUB DWORD point

Your original code of XX$ = Air_Injector elicited an error presumably
because Air_injector is a label and XX$ is a string variable .

The three lines of code above could be written as ;

GOSUB DWORD CODEPTR(Air_Injector)

The main advantage of the GOSUB DWORD implementation is that Air_Injector need not be within the scope of the calling function; where as
GOSUB Air_Injector
must be within the scope, as well as various forms of the
'
On var GOSUB Air_Injector implementation

[Michael Mattias]

The main advantage of the GOSUB DWORD implementation is that Air_Injector need not be within the scope of the calling function

Some might consider that a dis-advantage, as it is explicitly not supported; from the help file (8.03) under GOSUB:

All labels and line numbers are private. You cannot GOSUB to a label outside of the current Sub or Function.

That is, don't be surprised if this fails miserably in a new release of the compiler.

Sounds to me like whatever is at the label Air_Injector should be re-written as a separate procedure so it may be called from any other procedures.