SpinTool function pointers

forthnutter

Just wondering if Spintool supports function pointers in P1 Spin.
I think I have seen it used on other spin compilers.

macca

No, function pointers are implemented in the P2 Spin interpreter, AFAIK, with the P1 rom interpreter is not possible to implement such functionality.

Other compilers may implement a custom interpreter code that allows to implement that, if I'm not wrong, flexspin has its own runtime interpreter but I don't know if it implements function pointers.

Wuerfel_21

Flexspin can do function pointers on the P1 ROM interpreter. You can compile something like that and look at the listing to see how it does it, but the gist is that it uses a helper function that takes the function pointer in INB (I think?) and then sets PCURR to jump into the method after doing some setup.

macca

@Wuerfel_21 said:
Flexspin can do function pointers on the P1 ROM interpreter. You can compile something like that and look at the listing to see how it does it, but the gist is that it uses a helper function that takes the function pointer in INB (I think?) and then sets PCURR to jump into the method after doing some setup.

I see, there are helper functions and a lot of other things, seems that it allocates some memory to do its magic with the code pointers.
I don't think I want to implement that.

forthnutter

Maybe its just spin compiler cannot interpret that command. I have notice the spin code "COGNEW" handles function pointers ok.
Will need to look into this bit more.

macca

@forthnutter said:
Maybe its just spin compiler cannot interpret that command. I have notice the spin code "COGNEW" handles function pointers ok.
Will need to look into this bit more.

COGNEW is a special case, it expects a method reference and handles that on its own.

I just noticed that you can use COGNEW(method, ...) and COGNEW(@method, ...) in Spin Tools, they are exactly the same and the latter is not compatible with other tools (I think), don't know why I did that, maybe because starting a PASM cog uses that syntax, but the @ prefix doesn't mean take the address in this case.

forthnutter

Maybe I am thinking that methods can be functions in propeller world.
I always get an error when I try to put method into a variable.

After I remove error and generates listing, it looks like two constant parameters are generated for the method, number maybe reference to something, does not look like an address.
The meaning must be in the spin interpreter. Might go have a look at that the spin source.

macca

@forthnutter said:
Maybe I am thinking that methods can be functions in propeller world.
I always get an error when I try to put method into a variable.

You should look at the error messages.

pointer := Loop ' expected 1 argument(s), found 0

That statements means call the function Loop and assign the result to pointer (it doesn't get the pointer, in spin1 methods are called without parenthesis when doesn't have arguments), however you defined PUB Loop(data) so you need to add an argument.

pointer := Loop(1) ' works

As said, method pointers in standard spin compiler/interpreter are not allowed, so pointer := @Loop is not valid.

The listing shows how the bytecode works, methods are referred with a CONSTANT ($0102) representing the method's index within the object and the number of arguments, the COGNEW opcode in the rom runtime decodes that value and does its magic to jump to the method.

Edit: actually, cognew is a bit misleading since it starts a new cog to run the method passed as argument, the bytecode that calls a method is like this:

'     Loop(1)
0001C 0000C       01             ANCHOR
0001D 0000D       36             CONSTANT (1)
0001E 0000E       05 02          CALL_SUB (1)

The concept is the same, the method is referenced as an index within the object, there is no way to specify that without using some helper functions that manipulates the runtime variables.