spin2cpp version 1.01
ersmith
Posts: 6,092
There's a new version of spin2cpp, the Spin to C/C++ converter, available from http://code.google.com/p/spin2cpp. Version 1.01 fixes a few bugs (like the missing <= and =<= operators) and also has slightly cleaner C/C++ output: constants are now output as the constant name rather than a literal value.
Eric
Eric
Comments
Out of curiousity, is this going to be part of PropGCC? Or, are you keeping it seperate?
ran this command line:
C:\testing>spin2cpp --main --ccode --files femtobasic.spin
this was returned:
vga_Drive.spin:284: syntax error
1 errors
Thanks for the bug report -- it'll be fixed in the next version of spin2cpp. In the meantime you can change lines like: into the equivalent which spin2cpp does understand.
Eric
I've attached the code to this post.
Edit: it works if I remove the --gas option.
Edit2: It also works (with the --gas option, but without the --elf option) with this makefile:
I suspect it's because I compile each into a .o file, and then link them? I get the same error as above (not within region) if I try the propeller-elf-gcc with the three .cpp filenames.
Also, I learned that propeller-elf-gcc *.cpp will match all the cpp files. I didn't know that GCC does wildcard matching.
The following Spin code (except, full source attached to post), when run through spin2cpp, causes a segfault.
The GDB of the core dump is:
The problem is the \ in line 4 of the except above (line 31 of test_nl.spin, which is the top level file). When this is removed spin2cpp seems to function correctly.
Interestingly, the only other \ in the program doesn't cause spin2cpp to crash, one way or the other.
spin2cpp does not seem to recognize the array indicator ( [ n ] ) for objects. It simply drops the array index in the generated code.
I have attached the problem code, both the .spin source and the spin2cpp generated files. Here is the compiler output (the errors are near the bottom).
Edit: Ok, so it looks like the .spin source used a syntax of "object" to mean "object[0]". So that's probably the reason why spin2cpp didn't work: it doesn't make that conversion in the case of an array of objects.
Thanks for the detailed bug reports! I've fixed those problems, and I should have a new version of spin2cpp out in the next day or two.
Eric
I've determined that the problem is in safe_spi_na.cpp. The issue is that it uses a DAT section (at the top of the program) to store variables, and in the --gas generated code the variables are included in the GAS output: Changing the Spin code so that the variables are in a VAR block solves the issue. I don't know how this issue is affected by DAT blocks after a PASM block.
1) Copying function comments (almost always after a PUB or PRI in Spin) to it's equivalent in the .h file
2) Copying the ASM comments (when the --gas option is enabled), since the commands are directly copied.
It would be nice if the comments in a function body were able to come along as well, but I assume that would be more difficult.
The goal of this request would not be to make a "perfect" conversion of the comments. I already expect to go through the code and clean it up anyway. Rather, this would save the effort of having multiple files open and copying the comments between them.
Marking all variables as volatile will have a significant performance impact, since it inhibits a number of optimizations and prevents variables from being cached in registers. So I don't think it's a good idea to make that the default -- you could just as well always compile with -O1 or no optimization instead. It is possible to include {++volatile} as a comment in the spin code to force a variable to be volatile: will generate in the C++ output. Another option might be to mark variables whose address is taken as volatile as well... that might get us a lot of the way there.
Regards,
Eric
Thanks for that tip. I like the option of being able annotate the Spin file. Is there something similar that I can do for the DAT blocks?
The problem: I have a set of spin files (attached), and when I compile them with just --main it works. But when I add in the --gas, the program returns the not mounted warning:
This seems to be a bug in the --gas output. I know it's not a problem with the card or the code because the Spin program works fine, and the non--gas option works fine. I can run the working version of the program before and after the failure, so it's not setting the SD card in an unusable state or anything.
A little bit of digging seems to indicate that the FS type is all 0's in the failing version (instead of a byte reversed "FAT32"). Other than that, I don't know where the problem is.
I get the following spin2cpp output:
The code compiles fine with BST. If change the code to not use the range (an outa on each line, with a single pin argument) then spin2cpp works.
The code is from post #9 in this thread: http://forums.parallax.com/showthread.php?143483-Make-an-LED-pulse-(smoothly-go-on-and-off)-without-any-code-interaction
I'm not sure if this is a bug, since it seems like spin2cpp caught it. Maybe PropGCC doesn't support non-constant ranges like that?
There isn't at the moment, but I'll add the same feature (so you can put {++volatile} right after the DAT statement to make the DAT block volatile).
Incidentally, you can also put whole blocks of C code in a {++ ... } comment. Here's a made up example where we override the Spin version of methods with C versions; this is useful for putting both Spin and C/C++ wrappers to PASM in the same file:
It's not actually a PropGCC issue, it is spin2cpp that's at fault -- at the moment it doesn't know how to deal with non-constant ranges (which require generation of run time code to sort out the upper and lower bounds). That's a feature that's still on the "to-do" list :-).
I'm not sure what's going on with your other example (the problem with GAS) but I'll take a look at it.
Thanks for the bug reports,
Eric
Eric
Superb effort with this program.
I've gone from a Hello World to a full calculator program which uses Kye's SD engine in the background. Sorry about pushing your program right to the limit!
Compile with
which creates 4 .h and 4 .c files
Getting multiple errors in the C code:
I see you have done some bug fixes and I'm on the version from a few weeks ago.
If you can take a look some time that would be very much appreciated
It works for me. I can convert your code with the command given (after fixing for correct filenames, ie SPI_ASM), and compile with the following commands:
I don't get any compile errors. I suspect the problem may be in your makefile.
Edit: I tested with the older version of spin2cpp (1.01).
Edit2: What version of PropGCC are you using? If you didn't build it on your computer, it's probably too old.
Not all the features of spin2cpp work with Catalina yet, and abort is unfortunately one of them. I hope to fix this eventually, but in the meantime you could try compiling it with PropGCC.
Eric
BTW what was wrong with the SPI_ASM again - was it the underscore or something else?
It was the filename: linux requires it to match exactly with what the OBJ sections requests.
re Eric
I note that Kye uses abort a lot in his objects, especially abort with a backslash. I'm reading about abort now. Is there a C equivalent?
There are 3 pages on abort in the manual and I have to confess that I don't really understand all of it very well, eg
Coding all that into C may not be all that easy!
Using abort we end up with A calls B calls C calls D calls E which may ABORT.
In that case control returns to E and immediately to D and immediately to C and so on until A returns which basically halts your program.
Unless someone in the chain is using that backslash in which case the roll back described above stops an that point and whoever it was using the backslash can do something about the failure. Try again or print a message or whatever.
The C language does not really have this but it can be implemented with the setjmp() and longjmp() functions, Knd of like a goto that can get you back somewhere far away from your current function.
As in the example here : http://publib.boulder.ibm.com/infocenter/tpfhelp/current/index.jsp?topic=%2Fcom.ibm.ztpf-ztpfdf.doc_put.cur%2Fgtpc2%2Fcpp_longjmp.html
Basically setjmp remebers a place in the code but also a particular state of the stack at that time. Longjmp gets you back there and restores the stack to that state as well so that everything can proceed nicely.
Sounds like with that ABORT will show up in spin2cpp one day.
Wait a min, if you are generating C++ that has exceptions which should be able to do something similar.
Slight correction: I got it working in GCC C, which according to this post, is C89. The "gcc" compile command will compile .c files as C, not C++. It will, however, switch over to C++ for .cpp (etc.) files. The "g++" command will compile all files as C.
Abort is already in Spin2Cpp as a macro (at least in the cpp version, I haven't tried the --ccode option). You can see it by converting a program that already has it such as FSRW.