Translating the Spin Obex to C
Dr_Acula
Posts: 5,484
I think it may now be possible to translate pretty much *any* spin program to C!
Attached is a photo - proof that it is possible to run a large program like Kyedos in C.
Steps along the way.
1) Run your Spin program through Spin2cpp. I used a batch file that looked like this
3) If duplicate errors appear in the compilation, close SimpleIDE and edit the .side file
4) Some filenames don't work, eg tv.spin was a problem as tv was used somewhere else, so rename the original spin files
5) Use a large ram chip, the 24LC1024 has plenty of room for a (max 32k) spin program (which compiles to more than this in C, 57k for Kyedos)
For my reference, these two threads http://forums.parallax.com/showthread.php/147159-23LC1024-driver and http://forums.parallax.com/showthread.php/146794-Help-with-compile-errors
Lots of helpful contributions along the way from many very kind people.
There are some clever things going on in Kyedos - one thing that is not entirely obvious from the screenshot is that this is running its own SD driver (and keyboard, and display). So there are no C drivers being used. This is spin code being translated into C. This is possible due to the recent drivers for C that can cache the C program from an SPI ram chip, as there would obviously be conflicts if the C program were cached from the same SD card that a a program wanted to use.
This is all very exciting. Kyedos was chosen as it uses some quite complex Spin programs (11 in total) from the obex, and if this can compile and run then other obex code ought to run as well.
Suddenly, the 'library' of C code available to the propeller is a lot bigger!
Attached is a photo - proof that it is possible to run a large program like Kyedos in C.
Steps along the way.
1) Run your Spin program through Spin2cpp. I used a batch file that looked like this
spin2cpp --main Kyedos3_TV.spin pause2) Open SimpleIDE and add all the relevant .cpp files by right clicking on the menu area on the left side of the screen
3) If duplicate errors appear in the compilation, close SimpleIDE and edit the .side file
4) Some filenames don't work, eg tv.spin was a problem as tv was used somewhere else, so rename the original spin files
5) Use a large ram chip, the 24LC1024 has plenty of room for a (max 32k) spin program (which compiles to more than this in C, 57k for Kyedos)
For my reference, these two threads http://forums.parallax.com/showthread.php/147159-23LC1024-driver and http://forums.parallax.com/showthread.php/146794-Help-with-compile-errors
Lots of helpful contributions along the way from many very kind people.
There are some clever things going on in Kyedos - one thing that is not entirely obvious from the screenshot is that this is running its own SD driver (and keyboard, and display). So there are no C drivers being used. This is spin code being translated into C. This is possible due to the recent drivers for C that can cache the C program from an SPI ram chip, as there would obviously be conflicts if the C program were cached from the same SD card that a a program wanted to use.
This is all very exciting. Kyedos was chosen as it uses some quite complex Spin programs (11 in total) from the obex, and if this can compile and run then other obex code ought to run as well.
Suddenly, the 'library' of C code available to the propeller is a lot bigger!
Comments
Very cool. Are you using CMM?
I have a feeling ZiCog is going to be put through the wringer soon.
No, xmmc.
There are aspects of Zicog that could do well with GCC. I have an idea that you go back to the 8080 code and really try to fit as much of that in one cog. But for the bits that don't fit, run those from cache code in C. Slower, but hardly used instructions like DAA could be written in C.
The other thing with Zicog is that you could look at the 64k memory of a Z80 in a different way. Instead of running the program from external parallel sram, instead use slower serial ram but use the cache code. So the Z80 requests instruction n, and n gets passed to the cache driver and if that block is in hub ram which it will be most of the time, it avoids many external ram loads.
I'll think about it some more. We never had caching with the original zicog, and caching both speeds things up, and reduces the chip count. Just one 8 pin chip for the memory. Lots of free pins, even with some allocated to display, some to keyboard and some to serial ports.
The cache code/methodology could be leveraged, but I'm not sure propeller-gcc would help otherwise. Regardless, I look forward to watching the effort.
@heater, we can do things in C that can't be done in spin. Take a Z80 emulation that happens to be running CP/M, and it is loading a file off an SD card into memory. The C program is running from an external ram chip, and the memory of the Z80 is also in the external ram chip. Declare a 64k file in a C program. Write some code to read data from the SD file (or just run a Spin driver through spin2cpp).
There are two things going on behind the scenes in C. The code will have cached the part of the array that it needs to be writing to (I presume that happens?). And the code will also have cached in the segment of code that is reading the SD card.
As long as those blocks of code are small, it should all now be cached into hub. This ought to be true - say the blocks are 2k in size and the cache is 8k. Once the setup is done, the actual code that reads off the SD card is fairly small. And for CP/M, the file blocks are 128 bytes so that will fit in a 2k cache block.
On the dracblade sram, I think it was about 20 pasm instructions to get a byte off external ram. With a cache driver, there are a few overheads, such as checking for cache hits or misses. But it ought to be a lot less than 20 instructions overall, esp since most reads and writes are going to be directly to hub.
It should result in a much faster emulation, right?