This is for anyone entertaining openspin as a replacement for bstc.
1. It is necessary to spell out the .dat file in the -o output even if -c was specified.
2. It is necessary to spell out the .binary file in the -o output even if -b was specified.
3. I can only guess at this point that the same is true for .eeprom with -e specified.
The bstc program will do those things for you.
I'm building propeller-gcc linux release packages at the moment with openspin.
Code is not committed yet.
I actually like the way openspin does it better than bstc. Probably better to let the programmer choose the extensions rather than automatically providing them. At least that's the way most Linux tools work.
There's no reason OpenSpin could not work that way, too. Just invoke it from a short .bat file or bash script that fills in the default file suffices. It's actually more flexible that way than bstc. Heck, you could even name the bash script bstc. Who would know?
But if you actually get the open source spin compiler and run it with no parameters it prints out the following:
$ /opt/parallax/bin/openspin.linux
Propeller Spin/PASM Compiler 'OpenSpin' (c)2012-2013 Parallax Inc. DBA Parallax Semiconductor.
Compiled on Oct 21 2013
usage: openspin
[ -h ] display this help
[ -L or -I <path> ] add a directory to the include path
[ -o <path> ] output filename
[ -b ] output binary file format
[ -e ] output eeprom file format
[ -c ] output only DAT sections
[ -d ] dump out doc mode
[ -t ] output just the object file tree
[ -f ] output a list of filenames for use in archiving
[ -q ] quiet mode (suppress banner and non-error text)
[ -v ] verbose output
[ -p ] disable the preprocessor
[ -a ] use alternative preprocessor rules
[ -D <define> ] add a define
[ -M <size> ] size of eeprom (up to 16777216 bytes)
<name.spin> spin file to compile
Which is probably all the documentation you need apart from the usual Parallax Spin/PASM language manuals.
Well, except that there's a preprocessor in there somewhere. I can probably guess at the functionality and syntax of the preprocessor, but I thought it might be documented somewhere. So the functionality shown in the usage output is a complete list? Nothing else I need documentation for?
The "alternate preprocessor rules" are somehting I added to Catalina's version of OpenSpin to make the preprocessor behave the way I needed it to (the original had some funny quirks - not wrong exactly, just ... odd.
Actually, I was hoping I'd read that inline assembler was available in OpenSpin... Is that not a possibility?
Nice handle, R. Daneel!
No, inline assembly is not possible in Spin. In C it is possible because the C compilers first load a "kernel" that knows how to execute binary code fetched from hub RAM long-by-long.
Spin has no equivalent - it only executes binary by loading entire 512 long "chunks" into a cog.
The "alternate preprocessor rules" are somehting I added to Catalina's version of OpenSpin to make the preprocessor behave the way I needed it to (the original had some funny quirks - not wrong exactly, just ... odd.
So I take it it's not a hook of some sort to an external preprocessor?
So I take it it's not a hook of some sort to an external preprocessor?
-Phil
No, it just changes the semantics of the existing preprocessor slightly. From memory, the only significant change is that symbols that are just "#defined" but not given a value are not used in macro substitutions. This was a fairly simple way of getting around a problem I had with the preprocessor doing macro substitutions within hexadecimal constants and in some other places you would not normally expect.
For example:
#define BEEF
DAT
XXX long $BEEF
PUB START
This compiles under both sets of preprocessor rules - but only compiles as you would probably expect if -a is used. The -a rules are more like the ones implemented by Homespun.
While the original preprocessor rules are not strictly wrong, they are just not well suited to Spin, and can lead to some very difficult to locate bugs!
No, it just changes the semantics of the existing preprocessor slightly. From memory, the only significant change is that symbols that are just "#defined" but not given a value are not used in macro substitutions. This was a fairly simple way of getting around a problem I had with the preprocessor doing macro substitutions within hexadecimal constants and in some other places you would not normally expect.
For example:
#define BEEF
DAT
XXX long $BEEF
PUB START
This compiles under both sets of preprocessor rules - but only compiles as you would probably expect if -a is used. The -a rules are more like the ones implemented by Homespun.
While the original preprocessor rules are not strictly wrong, they are just not well suited to Spin, and can lead to some very difficult to locate bugs!
Ross.
Which brings me back to my original question... Are the preprocessor rules - original and alternate - documented anywhere?
Which brings me back to my original question... Are the preprocessor rules - original and alternate - documented anywhere?
Not to my knowledge.
However, there is only one file (preprocess.c) and here is the header it contains:
* Generic and very simple preprocessor
* Copyright (c) 2012 Total Spectrum Software Inc.
* MIT Licensed, see terms of use at end of file
*
* Reads UTF-16LE or UTF-8 encoded files, and returns a
* string containing UTF-8 characters.
* The following directives are supported:
* #define FOO - simple macros with no arguments
* #undef
* #ifdef FOO / #ifndef FOO
* #else / #elseifdef FOO / #elseifndef FOO
* #endif
* #error message
* #warn message
* #include "file"
I'm not sure who "Total Spectrum Software" actually is - but it may include people here in the forums who can chime in with more detail.
However, there is only one file (preprocess.c) and here is the header it contains:
* Generic and very simple preprocessor
* Copyright (c) 2012 Total Spectrum Software Inc.
* MIT Licensed, see terms of use at end of file
*
* Reads UTF-16LE or UTF-8 encoded files, and returns a
* string containing UTF-8 characters.
* The following directives are supported:
* #define FOO - simple macros with no arguments
* #undef
* #ifdef FOO / #ifndef FOO
* #else / #elseifdef FOO / #elseifndef FOO
* #endif
* #error message
* #warn message
* #include "file"
I'm not sure who "Total Spectrum Software" actually is - but it may include people here in the forums who can chime in with more detail.
Ross.
Total Spectrum Software is Eric Smith's company. He wrote the preprocessor as part of spin2cpp.
I just raised an issue re: DAT section extraction. If the (SPIN) file in question doesn't include a child object then the first and last long go AWOL. Quick fix is to include a dummy object.
It had been too long without an update, and I had bug fixes and changes I wanted to get submitted. So I undid some of my more drastic changes locally (saved so I can redo them again), and did a new build and tested it against the 1400+ obex/PropTool files and it's stable. My next big update will include significantly more refactoring, and the first pass at the new API for the compiler.
I also decided to update and add to the wiki/docs on the google code page, hopefully this helps.
Updated the source code with a fix for one file with a bad path separators which would cause non-windows builds to fail. It's r66.
Thanks to zeti for catching this so quickly, and letting me know.
... did a new build and tested it against the 1400+ obex/PropTool files and it's stable. ...
When you test, do you just check that the item compiles without errors, or do you also check that the code produced is identical to the proptool? just curious.
prof_braino,
The test compares the binary output of propellent with the binary output of openspin. Of the 1465 files tested, 55 of them have minor binary differences that are all confirmed to be due to the difference in floating point compliancy causing number constants to be slightly different (more correct due to being IEEE compliant now), and there are 6 files that propellent fails on, but openspin succeeds due to the files having preprocessor directives (people put files in obex that required bstc or homespun to compile previously).
Put up a new build, r68, see first post for details.
The -s part doesn't work for files above a certain size. The one below being one example. If you remove/empty the DAT section it works.
CON
_clkmode = XTAL1|PLL16X
_xinfreq = 5_000_000
CON
#0, XI_0, XI_1
#2, XO_0, XO_1 ' temporary extractor outputs
PUB null
DAT
{
Avoid popularity if you would have peace. - Abraham Lincoln
Ballots are the rightful and peaceful successors to bullets. - Abraham Lincoln
Better to remain silent and be thought a fool than to speak out and remove all doubt. - Abraham Lincoln
Books serve to show a man that those original thoughts of his aren't very new at all. - Abraham Lincoln
Character is like a tree and reputation like a shadow. The shadow is what we think of it; the tree is the real thing. - Abraham Lincoln
Common looking people are the best in the world: that is the reason the Lord makes so many of them. - Abraham Lincoln
Discourage litigation. Persuade your neighbors to compromise whenever you can. As a peacemaker the lawyer has superior opportunity of being a good man. There will still be business enough. - Abraham Lincoln
Don't interfere with anything in the Constitution. That must be maintained, for it is the only safeguard of our liberties. - Abraham Lincoln
Every man is said to have his peculiar ambition. Whether it be true or not, I can say for one that I have no other so great as that of being truly esteemed of my fellow men, by rendering myself worthy of their esteem. - Abraham Lincoln
}
DAT
Thanks for adding the -s option to OpenSpin!! I've modified spinwrap to use it and have placed the sources on GitHub. I think you said that OpenSpin was destined for GitHub as well so I figured that was a good choice. This means you can grab the sources for spinwrap without having to also get the entire propgcc repository on Google Code.
I've setup the github copy of OpenSpin here: https://github.com/reltham/OpenSpin
I've left the googlecode one as is, since it has the revision history.
I tried following some stuff to get the history stuff into git, but it was all very painful and craptacular wanting me to use linux and have Ruby installed for one tool, or just not working at all for the 3 other step by step instructions I tried to follow.
It's not like it matters much, I have the latest rev of the code in github, and the readme/wiki stuff is all up to date. Not sure what to do about the next build since it won't be r70 (or whatever) since git commit numbers are SHA values, and I think those would be confusing for the binary zips. Maybe, I'll just start the next one at 1.00, and go up from there.
Comments
-Phil
No more futzing around with .dat files when building propgcc on the Raspberry Pi and other ARM platforms.
Great stuff.
But if you actually get the open source spin compiler and run it with no parameters it prints out the following:
Which is probably all the documentation you need apart from the usual Parallax Spin/PASM language manuals.
-Phil
I just put Spin files in and get binaries out.
Phil,
Good question. Where is Roy when you need him?
The "alternate preprocessor rules" are somehting I added to Catalina's version of OpenSpin to make the preprocessor behave the way I needed it to (the original had some funny quirks - not wrong exactly, just ... odd.
Ross.
Nice handle, R. Daneel!
No, inline assembly is not possible in Spin. In C it is possible because the C compilers first load a "kernel" that knows how to execute binary code fetched from hub RAM long-by-long.
Spin has no equivalent - it only executes binary by loading entire 512 long "chunks" into a cog.
Ross.
-Phil
No, it just changes the semantics of the existing preprocessor slightly. From memory, the only significant change is that symbols that are just "#defined" but not given a value are not used in macro substitutions. This was a fairly simple way of getting around a problem I had with the preprocessor doing macro substitutions within hexadecimal constants and in some other places you would not normally expect.
For example:
This compiles under both sets of preprocessor rules - but only compiles as you would probably expect if -a is used. The -a rules are more like the ones implemented by Homespun.
While the original preprocessor rules are not strictly wrong, they are just not well suited to Spin, and can lead to some very difficult to locate bugs!
Ross.
Which brings me back to my original question... Are the preprocessor rules - original and alternate - documented anywhere?
Not to my knowledge.
However, there is only one file (preprocess.c) and here is the header it contains:
I'm not sure who "Total Spectrum Software" actually is - but it may include people here in the forums who can chime in with more detail.
Ross.
It had been too long without an update, and I had bug fixes and changes I wanted to get submitted. So I undid some of my more drastic changes locally (saved so I can redo them again), and did a new build and tested it against the 1400+ obex/PropTool files and it's stable. My next big update will include significantly more refactoring, and the first pass at the new API for the compiler.
I also decided to update and add to the wiki/docs on the google code page, hopefully this helps.
Roy
Thanks to zeti for catching this so quickly, and letting me know.
When you test, do you just check that the item compiles without errors, or do you also check that the code produced is identical to the proptool? just curious.
The test compares the binary output of propellent with the binary output of openspin. Of the 1465 files tested, 55 of them have minor binary differences that are all confirmed to be due to the difference in floating point compliancy causing number constants to be slightly different (more correct due to being IEEE compliant now), and there are 6 files that propellent fails on, but openspin succeeds due to the files having preprocessor directives (people put files in obex that required bstc or homespun to compile previously).
Phil Pilgrim wrote the tool that I am using.
You are my best bug finder!
I found the problem, I'll have a fix up in a while.
Thanks for adding the -s option to OpenSpin!! I've modified spinwrap to use it and have placed the sources on GitHub. I think you said that OpenSpin was destined for GitHub as well so I figured that was a good choice. This means you can grab the sources for spinwrap without having to also get the entire propgcc repository on Google Code.
Here is the URL: https://github.com/dbetz/spinwrap
I've left the googlecode one as is, since it has the revision history.
I tried following some stuff to get the history stuff into git, but it was all very painful and craptacular wanting me to use linux and have Ruby installed for one tool, or just not working at all for the 3 other step by step instructions I tried to follow.
It's not like it matters much, I have the latest rev of the code in github, and the readme/wiki stuff is all up to date. Not sure what to do about the next build since it won't be r70 (or whatever) since git commit numbers are SHA values, and I think those would be confusing for the binary zips. Maybe, I'll just start the next one at 1.00, and go up from there.