spin2cpp version 1.05
ersmith
Posts: 6,054
I've uploaded spin2cpp version 1.05 to http://code.google.com/p/spin2cpp/. This is a bug-fix release fixing a number of issues that have come up in the past few months (and hence improving compatibility with Spin in general).
Spin2cpp is a converter from Spin to C/C++. It's primarily designed to produce C++ for propgcc, but can also produce ANSI C that can be compiled with Catalina. PASM code can be converted to a binary array or to propgcc inline assembly (the latter is not as thoroughly tested). Many Spin objects can be converted directly with spin2cpp. Some others will need a bit of tweaking to the output. The most common problem is variables needing to be marked "volatile" for the C compiler (spin2cpp can't usually detect when multiple COGs are modifying the same variable).
Spin2cpp is a converter from Spin to C/C++. It's primarily designed to produce C++ for propgcc, but can also produce ANSI C that can be compiled with Catalina. PASM code can be converted to a binary array or to propgcc inline assembly (the latter is not as thoroughly tested). Many Spin objects can be converted directly with spin2cpp. Some others will need a bit of tweaking to the output. The most common problem is variables needing to be marked "volatile" for the C compiler (spin2cpp can't usually detect when multiple COGs are modifying the same variable).
Comments
Happy New Year.
I'm having some problems with the converting a VGA driver. It is giving the error below, but also this is not the correct line number, and changing lines near this don't seem help either. Am I doing something wrong here?
Any help would be most appreciated
OK, make :cursor a non-local label, then it works. This needs to be sorted though.
Thanks for the bug report,
Eric
Or are we looking at two different bugs here?
I just checked and it doesn't seem to match -- there are 2 bytes different (probably hard to see if looking at it manually). In the original spin2cpp the if_nc_or_nz condition isn't being applied to the appropriate instruction. (I'm assuming we're talking about VGA_HiRes_Text_010.spin, but the problem will apply to any code that used if_nc_or_nz.)
There is also another difference with the bstc output, which is that the labels on org instructions aren't being handled the same. I'll look into that as well.
Still not sure what to do with this though - I get multiple errors when I then run the code through SimpleIDE and try to compile. I think I am not using Projects correctly in SimpleIDE, and manually copying the main block of text into the main window may be the source of the errors. The Help menu in SimpleIDE leads to a broken link on the propeller forum. I've not quite got my head around the SimpleIDE system - it has associated the .cpp extension with the program, but click on a .cpp file and it seems to open a project from last year rather than the file I clicked. I'm not sure how to start a new project and link it to a group of files created by spin2cpp.
Plan B - go back to Spin2CPP and try to compile to C89 with a view to running this in Catalina. It *almost* compiles, but KyeDOS has several references to the SD object - one called fat and one called taf. This is for file copying on the SD card - I think Kye just duplicated the object. Unfortunately this generates an error in spin2cpp - see screenshot.
Would it work to clone this duplicate object and give it a different name?
Seriously consider reading the spin2cpp userguide. https://propgcc.googlecode.com/hg/spin2cpp/Readme.txt
Most SPIN users don't get SimpleIDE because it requires a project like most other programming platforms.
Complaining about errors without seeking help by posting more information or questions is not very useful.
Moving to Catalina won't help -- gcc generally produces smaller code. You could compile and link it in XMMC mode, but I highly doubt it will run -- getting XMMC and the SD card to play together is going to require some work.
What are you trying to accomplish here?
Eric
Push your clever programs right to the limit!
Ultimately, what I want to do is write large Spin programs that exceed the size of the propeller chip, but at the same time leverage off all the objects in the obex. I figure Kyedos is a place to start because it combines objects from several different authors, all with different programming styles. If kyedos works, then chances are many other objects will also work.
Hopefully the following won't start a language war, but imho Spin is a brilliant language, however it is limited by both memory size and by the fact that most programmers have never heard of it. C, on the other hand, is popular but for C on the propeller, the libraries are limited to those that have already translated, so it isn't as easy to use as the Spin/Obex combination.
Spin2cpp is the answer!
ok, more specifically, to run kyedos on C is going to need external memory, and because it uses the SD card, it is not going to be possible to use any of the external memory modes that are reading the program off the SD card as there would be conflicts. So it will need to store program/data in some sort of other external memory - I'm thinking a 23LC1024.
So hopefully that will be the answer to this problem.
SimpleIDE would be a very useful part of the equation. jazzed said
It's a fair cop.
Right, let's see if I can articulate why I find SimpleIDE hard to use. It is project based, and at the fundamental level, a Project is a text file that binds together components. So in an abstract sense, you think about projects rather than about C files. But SimpleIDE also seems to be C file based. When installed, it links .h and .cpp files to itself. But click on a .cpp file in windows exporer and it does not open that file. That is not really expected behaviour. What happens instead is that SimpleIDE opens the last project - which from a project point of view makes sense but not from the point of view of a program. SimpleIDE might say that there is no need to open a C file, because it couldn't do much with it anyway because it doesn't know about which board it is meant to compile it with, which compiler to use etc.
So let's take a look at a different project based program. How about .net
A likely first thing a user is going to do is start a new project. So that would be File/New. But this is not File/New Program. This is File/New Project, and that is what is on the menu. You can open files too, but it is not the first item on the menu. And you can save files but it is a bit convoluted. If you have a project open, and if you have the solution explorer open on the right side, and if you have an item in that highlighted (eg a program, or a form), and then if you go to the File menu on the right side, there are options that appear that allow you to load and save individual items. The other way .net works is that it has a dynamically changing File menu which defaults to mainly all the project options, but if you did open a file, then new options appear which allow Save and Save As for that file. However, having a dynamically changing File menu is more complicated to code.
Maybe this is not the best way of doing things, but it hightlights the general idea that the obvious, intuitive options are based around Projects, and the complicated, harder to find options are for individual files.
I think this is where my confusion with SimpleIDE comes about, because SimpleIDE has the files in the main menu, and the project is in another menu.
So this is a suggestion - swap the menus around. The items in File refer to Projects, and the items in another menu (not sure what to call it, as File would be confusing) refer to individual cpp and h files.
Maybe then it might also be possible to think more about what happens with individual .cpp files. Let's say you start a Project and you want to import a vga object. In this sense, you are not really just opening the file vga.cpp, but rather, you are importing or including vga.cpp in your project. So rather than just opening vga.cpp in a new tab, maybe there needs to be a few options, like asking whether this file is now to be added to the project, and whether if the project is saved, this file is now part of the project package.
There are some other odd issues with simpleIDE - it seems to revert to old programs and old settings, saving a project seems to sometimes crash the program, and it brings up a menu tree to save a project when saving, when presumably this was set when the project was created. It is also not entirely obvious what is being compiled - I have solved this by having some old programs with specific behaviour like printing the name of the program on the screen so I can track which program actually got compiled when the build button is run. I have changed projects and compiled many times and been convinced code works when it was actually compiling a previous project. It seems to work very well once you have it set up with a particular project and particular settings, but the problems are when you change to a new project. I can write this up in more detail if needed.
I hope this makes sense
that sounds a plan. Working through the documentation.
I'll cheat for the moment and just delete the line in the integertodecimal routine that is failing.
so this is my batch file
and yes that creates an error as it is out of memory.
Right now, I have a hello world working on SimpleIDE and using C++, XMMC and a board configuration in a file 23LC1024 with the following settings
# 23LC1024.cfg clkfreq: 80000000 clkmode: XTAL1+PLL16X baudrate: 115200 rxpin: 31 txpin: 30 cache-driver: spi_sram24_cache.dat cache-size: 8K cache-param1: 0x090B0A01 # 0xooiiccpp - oo=mosi ii=miso cc=sck pp=cs-protocol cache-param2: 0x08000000 # 0xssxxxxxx - ss=cs load-target: ramThis will download and run a hello world program and I'm fairly confident (bearing in mind the comments above about old settings in simpleIDE) that this is indeed running from external ram.
Let's try to convert and compile kyedos from the command line in a batch file.
Looking at the documentation, need to use xmmc mode as this is the mode that is working in simpleIDE.
The tutorial is here https://sites.google.com/site/propellergcc/documentation/tutorials/spin2cpp and it says so guessing a bit here for xmmc and try -mxmmc
no, spin2cpp doesn't like that
let's try a double negative
no that doesn't work either
so off to the web to find some examples of the syntax
hmm, seems a bit odd because the syntax simpleIDE is using is which is one negative -mxmmc. Maybe the order matters - trying it in a different order...
Ah, the order does matter! So this compiled
Next - does that compiled file know about 23LC1024 settings, probably not because that wasn't in the command line. So need to work out what to do with the compiled file - how to tell it to use the ram and how to download it...
ok, back to SimpleIDE with a working hello world
and that gives us the syntax for propeller load. Put that in a batch file...
And it works! Kyedos running in C. Amazing.
Only thing is - it is taking about 1 minute to startup (cf about 3 seconds for the spin version). ?? because it is being loaded from the serial ram, but then again, the loader is sending the data (57kb) to the ram much faster than that. Hmm - need to fix that somehow, and work out if it is a ram speed issue. I suspect loading off SD will be even slower, but maybe not.
Reading through this file
https://sites.google.com/site/propellergcc/documentation/propeller-loader
Need to presumably store the program on the SD card, then store a program to load it on eeprom. Have to get the syntax for this.
SD pins are CS=12, MOSI=13, SCK=14, MISO=15
I may need to modify the .cfg file I am using. http://propgcc.googlecode.com/hg/loader/Loader.pdf but I don't want the program to try to cache anything from the SD card otherwise it will clash with kyedos (which has its own sd driver, and which seems to work just fine). So I need it to know enough about the SD card to load kyedos from the SD card into spi ram, but just that. The data is in the c3.cfg file but I am a bit unclear what the variables clr, inc and addr are for the sd card. ? leave these out.
So in summary - need a program in eeprom that knows about the sd card, and loads kyedos.elf (? renamed to autorun.pex) and moves it to spi ram.
The long load time from ram is a mystery though.
Ah, thanks kuroneko! I missed the right justification, and forgot about the default array dereference (and spin2cpp also doesn't seem to get that right, I'll have to fix that).
Eric
Rather than loading kyedos.elf it's probably easier/faster to load a .binary file, which you can produce from the elf with propeller-load (I think it's the -s option).
I need to work on the spin2cpp documentation, obviously. I'm working on a lot of spin2cpp changes to make the output more human-friendly, so I'll ad documentation work to the to-do list.
Thanks for the feedback. I'll give that a try with loading the .binary file. It is a bit odd that it downloads to external ram in less than 10 secs (I have leds on the serial lines) but then takes a full minute for the program to start. The very first line in the program is vt100.start, ie starting up the display, so the screen should come to life straight away but that doesn't seem to happen. The delay cannot be with transferring hub to external ram, as the program is larger than the hub size. So the download must be sending it straight to external ram. So if it only takes a few seconds to write to external ram, why would it be taking so much longer to read from ram? The cache driver maybe?
I'm going to try other loading scenarios. The next one to try is the one that loads the .pex file on the sd card and a bootloader on the eeprom to load this file into external ram. But yes, the syntax is a bit tricky. The only clue with propeller-load.exe is that it either runs, or it fails and prints out all the options. But I am not sure what exactly the syntax means - eg with the sd card pins being equal to values, does that imply an = or does it (as in some examples) imply a : colon.
This syntax is wrong, but I guess it gives a clue what I think I want to do. I think it is -x, and I think the -D options need to be able to tell the eeprom what pins the sd card is on.
The long startup delay is a bit of a mystery. If the answer is not obvious, then will need to start pulling kyedos to pieces and leaving out large parts of the code and try to determine which part is taking so long.
Thanks++ again for this clever program!
I'm working on simplifying the problem. Attached is a very simple spin program called vga.spin, with one object - a VGA text driver (one of the original Chip one). Downloads and runs in spin in under 5 seconds. Run spin2cpp.bat and it also compiles and downloads in under 5 seconds. But then there is a 1 minute delay for the program to start.
To run, needs propgcc installed in the default location. Copy the file 23LC1024.cfg to c:\propgcc\propeller-load
Next experiment - just use a serial port demo, as that will help determine if it is the display driver that is the problem.
Addit: A simple demo with just a serial port starts up instantly.
So the 1 minute delay is increasingly looking like it is a VGA display problem.
kuroneko, you could be right on this one.
Next experiment - start a serial port, then start a vga display. Maybe the program *is* running, but the display hasn't started?
Results:
Ah, the program *is* running straight away. But the display does not come on for another minute.
kuroneko - it sounds exactly like a cnt rollover problem. How do you know things like that?!!
Another experiemnt - instant startup if running the VGA display from hub memory. So it is looking increasingly like it is a cnt delay introduced when running the same code from external memory in -mxmmc mode.
Ok, thinking ahead, it is going to be something in the standard vga80x40 object, and this uses two cogs to drive the display. Presumably any pasm code sent to the cog is going to be the same in C and Spin (it has to be, because we know the display works). So I'm inclined to look at the Spin code that starts the cogs rather than the pasm code that drives the cogs. Although there could be a cnt value sent to the cog code that is part of the problem.
This is the spin startup code and it does use cnt a few times
PUB start(BasePin, ScreenPtr, ColorPtr, CursorPtr, SyncPtr) : okay | i, j '' Start VGA driver - starts two COGs '' returns false if two COGs not available '' '' BasePin = VGA starting pin (0, 8, 16, 24, etc.) '' '' ScreenPtr = Pointer to 8,192 bytes containing ASCII codes for each of the '' 128x64 screen characters. Each byte's top bit controls color '' inversion while the lower seven bits provide the ASCII code. '' Screen memory is arranged left-to-right, top-to-bottom. '' '' screen byte example: %1_1000001 = inverse "A" '' '' ColorPtr = Pointer to 64 words which define the foreground and background '' colors for each row. The lower byte of each word contains the '' foreground RGB data for that row, while the upper byte '' contains the background RGB data. The RGB data in each byte is '' arranged as %RRGGBB00 (4 levels each). '' '' color word example: %%0020_3300 = gold on blue '' '' CursorPtr = Pointer to 6 bytes which control the cursors: '' '' bytes 0,1,2: X, Y, and MODE of cursor 0 '' bytes 3,4,5: X, Y, and MODE of cursor 1 '' '' X and Y are in terms of screen characters '' (left-to-right, top-to-bottom) '' '' MODE uses three bottom bits: '' '' %x00 = cursor off '' %x01 = cursor on '' %x10 = cursor on, blink slow '' %x11 = cursor on, blink fast '' %0xx = cursor is solid block '' %1xx = cursor is underscore '' '' cursor example: 127, 63, %010 = blinking block in lower-right '' '' SyncPtr = Pointer to long which gets written with -1 upon each screen '' refresh. May be used to time writes/scrolls, so that chopiness '' can be avoided. You must clear it each time if you want to see '' it re-trigger. 'if driver is already running, stop it stop 'implant pin settings reg_vcfg := $200000FF + (BasePin & %111000) << 6 i := $FF << (BasePin & %011000) j := BasePin & %100000 == 0 reg_dira := i & j reg_dirb := i & !j 'implant CNT value to sync COGs to sync_cnt := cnt + $10000 'implant pointers longmove(@screen_base, @ScreenPtr, 3) font_base := @font 'implant unique settings and launch first COG vf_lines.byte := vf vb_lines.byte := vb font_third := 1 cog[1] := cognew(@d0, SyncPtr) + 1 'allow time for first COG to launch waitcnt($2000 + cnt) 'differentiate settings and launch second COG vf_lines.byte := vf+4 vb_lines.byte := vb-4 font_third := 0 cog[0] := cognew(@d0, SyncPtr) + 1 'if both COGs launched, return true if cog[0] and cog[1] return true 'else, stop any launched COG and return false else stopand this is the C++ code
int32_t vga_80x40::Start(int32_t Basepin, int32_t Screenptr, int32_t Colorptr, int32_t Cursorptr, int32_t Syncptr) { int32_t _parm__0018[7]; _parm__0018[0] = Basepin; _parm__0018[1] = Screenptr; _parm__0018[2] = Colorptr; _parm__0018[3] = Cursorptr; _parm__0018[4] = Syncptr; Stop(); ((int32_t *)&dat[140])[0] = (536871167 + ((_parm__0018[0] & 0x38) << 6)); _parm__0018[5] = (255 << (_parm__0018[0] & 0x18)); _parm__0018[6] = -((_parm__0018[0] & 0x20) == 0); ((int32_t *)&dat[132])[0] = (_parm__0018[5] & _parm__0018[6]); ((int32_t *)&dat[136])[0] = (_parm__0018[5] & (~_parm__0018[6])); ((int32_t *)&dat[144])[0] = (CNT + 65536); memmove( (void *)&(*(int32_t *)&dat[492]), (void *)&_parm__0018[1], 4*(3)); ((int32_t *)&dat[504])[0] = (int32_t)(&(*(int32_t *)&dat[552])); ((uint8_t *)(int32_t)(&(*(int32_t *)&dat[436])))[0] = Vf; ((uint8_t *)(int32_t)(&(*(int32_t *)&dat[156])))[0] = Vb; ((int32_t *)&dat[508])[0] = 1; Cog[1] = (cognew((int32_t)(&(*(int32_t *)&dat[0])), _parm__0018[4]) + 1); waitcnt((8192 + CNT)); ((uint8_t *)(int32_t)(&(*(int32_t *)&dat[436])))[0] = (Vf + 4); ((uint8_t *)(int32_t)(&(*(int32_t *)&dat[156])))[0] = (Vb - 4); ((int32_t *)&dat[508])[0] = 0; Cog[0] = (cognew((int32_t)(&(*(int32_t *)&dat[0])), _parm__0018[4]) + 1); if ((Cog[0]) && (Cog[1])) { return -1; } else { Stop(); } return 0; }That is a bug. Thanks.
The "main menu" shows File, Project, Edit, Tools, and Help.
File history is in the File menu. Project history is in the project menu.
Please find steps to repeat this problem with the latest version so that I can fix it. Thanks.
Ya, I've seen this issue first hand. It is clear in ProjectView. Using "SimpleView" certainly doesn't help this situation, but Parallax asked for it, so they got it.
Yes, changed $10000 to $40000 and it works. Problem fixed. Thanks++
I'll take this to a thread in the GCC forum because this could come up with anyone using external memory and displays.
@jazzed, there are all sorts of other things I find confusing in SimpleIDE, but perhaps that is because I am not using it for C programming, but rather more as a platform for Spin programming in conjunction with spin2cpp? So it is my problem that it is not doing what it is supposed to. My bad.
I see though that you are now working on a Spin IDE. I think all the pieces are in place now for Big Spin. It could be extremely simple - you have your spin IDE, you start coding, you run out of code space, you add a 23LC1024 chip and you click on "compile via spin2cpp" which runs spin2cpp and then propeller-load.
I thought I would try spinwrap with the KyeDOS3 zip you posted (especially as I had suggested that in another thread).
There was a minor bug in spinwrap, but it is resolved in the git repository now.
So, here's the way it goes ...
1. Ensure you have the latest openspin on the system.
2. Ensure you have the latest spinwrap on the system.
3. Unzip KyeDOS3.zip to some folder.
4. Run spinwrap as: spinwrap KyeDOS3.spin
5. Create a main .cpp project like below.
6. Compile, link, and download.
I had to change the SD card, VGA, and Keyboard settings for the Quickstart for testing, but it works fine.
/** * This is the main DraKyeDos.cpp program file. */ #include "KyeDOS3.h" int main(void) { KyeDOS3 dos; dos.shell(); return 0; }DraKyeDos.side contents
Please bear in mind that this is not a typical thing to do with spinwrap, but it does prove that a large SPIN program can be included directly into Propeller-C.
BTW invent-o-doc, if you're watching this it took more than the originally estimated 8 hours to add support, but no changes were required in the Propeller-GCC compiler or other tool code to make this work. Thanks to David Betz for spending time on it.
Cheers.
--Steve
That looks rather clever! Checking out spinwrap now...
Yes, spin2cpp can convert a complete spin program to a complete C program; in fact it can even invoke the compiler for you. It is *not* integrated into SimpleIDE (which quite properly is focussed on other things) but you can do it from the command line. For example, if all the .spin files are in the same directory and "main.spin" is the top level Spin file, then you would do: to get an executable binary main.binary, which can then be run with propeller-load or with any other propeller tools. (The -O says to optimize the output, which is usually recommended.)
Not all OBEX objects will necessarily work with spin2cpp, I think most will.
Thank you for the informative reply. I am very excited about the possibilities of using your software to develop my C-code from Spin files. Thank you for making this available for use.
Sincerely,
George