Positioning code/buffers at specific hub addresses while using spin - today's zoom meetup
Cluso99
Posts: 18,069
13Jan-2021
When using spin2 it is not possible to manually place variables, buffers, or hubexec code at specific hub addresses using any of the current compilers - pnut, PropTool or FlexProp.
Following discussion at today's zoom meetup, Chip suggested he could move the resident part of the spin interpreter (hubexec code etc) up into the top 16KB of hub ram where the debug code is being placed. Then he could modify the compiler to be able to produce relocatable spin code that could even be loaded as a binary block of code. He thought the changes would be minor.
The big advantages to this scheme are
* Code could be compiled as a self-contained relocatable object (binary)
* This binary could be loaded when required, and to some alternate hub address
* PASM code could now be compiled separately and positioned in hub as and where it was required
IMHO this is an easy way to be able to position where we want to place code, variables and buffers. I think this will enhance the usability between the various languages too.
If Eric could do something similar in FlexProp we could have the advantage of being able to pre-compile binary objects that are in spin bytecode (pnut and PropTool) or compiled PASM (FlexProp).
I know there will be a few gotchas to work out, but this method seems to be a win-win for minimum work and maximum flexibility
We already have the FILE command that can include a compiled binary.
It would also be nice to have support in pnut and PropTool for the #INCLUDE command similar to FlexProp. #INCLUDE just includes the file as source data in the current source file for compiling. This has sadly been missing on P1 which is why many of us use bst, homespun or OpenSpin rather than PropTool.
When using spin2 it is not possible to manually place variables, buffers, or hubexec code at specific hub addresses using any of the current compilers - pnut, PropTool or FlexProp.
Following discussion at today's zoom meetup, Chip suggested he could move the resident part of the spin interpreter (hubexec code etc) up into the top 16KB of hub ram where the debug code is being placed. Then he could modify the compiler to be able to produce relocatable spin code that could even be loaded as a binary block of code. He thought the changes would be minor.
The big advantages to this scheme are
* Code could be compiled as a self-contained relocatable object (binary)
* This binary could be loaded when required, and to some alternate hub address
* PASM code could now be compiled separately and positioned in hub as and where it was required
IMHO this is an easy way to be able to position where we want to place code, variables and buffers. I think this will enhance the usability between the various languages too.
If Eric could do something similar in FlexProp we could have the advantage of being able to pre-compile binary objects that are in spin bytecode (pnut and PropTool) or compiled PASM (FlexProp).
I know there will be a few gotchas to work out, but this method seems to be a win-win for minimum work and maximum flexibility
We already have the FILE command that can include a compiled binary.
It would also be nice to have support in pnut and PropTool for the #INCLUDE command similar to FlexProp. #INCLUDE just includes the file as source data in the current source file for compiling. This has sadly been missing on P1 which is why many of us use bst, homespun or OpenSpin rather than PropTool.
Comments
Mike
There's actually two issues here:
(1) Making relocatable code is good, it does make it easier to move things around and may help with inter-language operability.
(2) Having absolute addresses in objects is the opposite, and will reduce usability between languages, because very few compilers are going to be able to support this. It's not something you can do in the C language, for example.
At the moment flexspin cannot produce position independent (relocatable) code. But you can specify the address where the code should run as a command line argument (I think it's -A, don't have a manual handy). So you can certainly use flexspin to make a binary blob that you include in a PASM or Spin2 program. The OS example I posted a while back does just that.
I wish I could make today's meeting, but my wife's in the hospital and on top of that I'm behind on my real, bill-paying work, so I probably will have to give this one a miss.
I do however wish for a linked list of subroutines so it's possible to look up where it is by name.
Another concept is dll's. Search for a driver by filename or guid or short name, and get the external references resolved before or during code execution.