Calling Spin from C
Keith D
Posts: 15
Hi
I was wondering if it would be possible to now run a spin object from within C code?
I know that the Spin Interpreter source has been released, and I was wondering about the practicalities of converting the interpreter into a C library so that all the spin libraries that have been developed could be used.
Is anyone working on a project like this?
Cheers
Keith
I was wondering if it would be possible to now run a spin object from within C code?
I know that the Spin Interpreter source has been released, and I was wondering about the practicalities of converting the interpreter into a C library so that all the spin libraries that have been developed could be used.
Is anyone working on a project like this?
Cheers
Keith
Comments
Imagecraft clearly state in their readme file that SPIN is never likely to be supported in any version of ICC for Prop.
Remember·your code runs within the constraints of LMM.
Ron
Only have to look at the work Hippy has done with Pnut.
But LMM would slow Spin down even further would it not ?
Ron
NO. Spin will run in its own COG. Multitasking with more than 1 processor and NO delay (almost) from access to shared memory
I assume the long Pnut_array is loaded into a new cog by ICC.
ICC starts cog..... code for Pnut is read from some HUB memory reserved for SPIN code.
I need to think on this one............
??
Ron
1) How to get compiled Spin bytecode to where it needs to be to suit the C memory layout.
2) How to interact between the two beyond peeking and poking shared RAM locations.
The ImageCraft development process is far more open and accessible than Parallax's Propeller Tool so it currently makes more sense to take ImageCraft output and launch C from within Spin. That's still not easy though and would need external tools writing to enable it.
With the demo and non-commercial C compilers not supporting command line invocation that makes it hard to create an elegant tool chain except for commercial compiler users. It is also IMO going to limit the incentive for people working towards such tools.
Being able to intermix code in C and Spin and casually call from Spin to C and vice-versa is possible but would need a whole new development environment adding and be a more complicated proposition.
Apart from doing it for the fun of it or to prove it can be done I don't really see the need or usefulness. The main argument in support is so C programmers can take existing Spin objects for use. A better approach IMO would be to convert Spin objects to C. Effort spent in doing that and automating the process would be far more useful IMO.
Such efforts are I believe most likely going to have to come from ImageCraft, C users or Spin programmers wanting to migrate to C. No offence intended to ImageCraft or C users, but I personally don't see any motivation for undertaking conversion or developing tools which would benefit commercial C compiler users but have almost no benefit for the wider Spin community, a similar ROI issue ImageCraft has identified. So, while it's possible, in the short term, I don't think C plus Spin is likely to happen. Others may however have entirely different ideas.
Yes, I think from your several postings on the subject that you don't care for the commercial C tools too much. I am just trying to make a living here...
Makes no sense at all IMO.
Ron
I like the idea of having well written/well documented shared libraries and objects but I feel that being able to call a spin object from C code (and vise-versa) would benefit everyone developing code as we could still share code without having to duplicate it in two languages!
A better thing to do than run spin is to make a spin to c pre-processor. It should be a fair bit easier and should make the spin code run a bit faster. However, the c version will probably use more space than the spin version.
The asm part is made easy be using the px.bat file. Just look at the C objects posted by jazzed. There is PX.bat which takes the binary output file and generates a long array Object_array.h ready to be loaded under C.
The tedious part is porting the SPIN component.
Ron
You can install Cygwin using http://www.cygwin.com/setup.exe . Or I could rent out my linux server [noparse]:)[/noparse]
The file makearray.bat let's you compile spin and run px.bat using one command. It requires the Propellent tool.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Post Edited (jazzed) : 6/27/2008 2:39:46 PM GMT
Strip the Spin source to just the PASM in the DAT, prefix with a PUB Main, F8 save the file as .binary or .eeprom, run Pasm2C. The included PasmCode.spin is the example to follow.
Do you use a fixed number to get the offset? I've found that sometimes a spin .binary file can be pulled in without any source modification if you allow selecting the start address. It can be tricky though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
More than one method and the start address gets pushed upwards. As there's no way to tell how many methods there are from the image it's a guess as to how far upwards and I think length might get harder to determine.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
1) Adjust the C compiler so stack start is moved down from top of memory, that space above will be used for the Spin program ( bytecode, vars and stack ). It will be a smaller version of Hub memory.
2) Put the entire Spin program above the C stack base.
3) Write a Spin Interpreter. Not as hard as it seems.
4) Create a syntax and implementation for a C program to call a Spin program in the C source. Because there are no names for Spin methods they'll have to be enumerated calls. This effectively compiles to a call into the C LMM.
5) Add the 'Call Spin' handler to the C LMM. This pushes a stack frame as a Spin method would expect when running plus any arguments etc. All the necessary information is in the Spin image to do this. Then jump to the Spin Interpreter to execute the selected Spin method.
6) Spin interpreter runs as it would be expected to, executes the method, launches new Cog's, calls other Spin methods etc etc. When the return from the first called method occurs the Spin interpreter jumps back to the C LMM and C carries on as normal.
Bingo - inline, same Cog, totally transparent Spin called by C.
C and Spin would be entirely isolated from each other only communicating through method call parameters so would need getters and setters as calls into objects do. It's pretty much how I'd run C from within Spin.
Off the top of my head, I'd guesstimate a week's work if able to jiggle the C compiler but depends on the tweaks needed to get the Spin interpreter working.
asm("@ldcnst\n"
".long 0x????\n"
"mov HRSP,TEMP0");
will put whatever you want to the HUB RAM stack. Of course, we can add a checkbox to the IDE for initial SP placement.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
@ Jazzed : That's PowerBasic Console Compiler (PB/CC) source. I can knock out a VB6 version if you'd like.
I'm much more interested in seeing your Cspin integration progress. Knowing you, it will be done by tomorrow [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I'm currently rewriting the spin interpreter (modifying) to run faster and it is looking good. As the bytecodes are being moved to table driven access, it should then be possible to call routines from any language (such as C). Also it should be possible to extend the spin interpreter using the unused bytecode.
My version still runs in a cog and uses hub ram tables to gain execution speed. I probably will need to use small overlays (or maybe LMM) for a few routines, but it is still too early to know how many routines will be done this way. My overlay routine hits the sweet spot.
see Spin Interpreter - Faster?? posting