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.