If BSTC compiles that and still only outputs 6 bytes with the -c option, then I think BSTC might be in error, because the fit directive should cause the label on the line with it to point to a long aligned address.
Looks like bstc simply ignores the alignment introduced by fit (but gets the label index right). The PropTool flags the DAT section as size 8 (expected) which is also what the compiled binary tells me. The previous size issue I was talking about (1022 bytes) is reached in a different way and openspin does that correctly now. Thanks for the quick fix.
Bill,
I have an update coming soon (maybe this weekend) that changes that. It handles it in a different way that should work across more platforms.
Others,
Just a heads up, this next update is going to do a lot of rearranging of the code (including splitting some stuff out into it's own files). It's something that's been needed for a while, and I finally got sick of the state it was in.
Also, it will *not* include the @@@ feature yet. That one turned out to be a more significant nut to crack because of how the compiler works, so I've shelved it for a bit in order to get some stuff done that Parallax requested. It'll get in there eventually.
After spending a little time attempting to at least get this thing to compile on Linux ARMv6 I am having zero luck. It does not help that it is C++ not C.
G++ (GCC C++ Compiler) keeps telling me that identifiers that are global to the source module are not declared in the current scope. Five languages that I really hate: C++, Java, VB, D, and C#, they are impossible to understand unless you are the programmer of origin and you commented the source well, and it has been less than 1 week since you created the source files.
OO in pure C is easier than mixed OO and procedural in C++.
I will attempt to translate these into C89 and compile that, a lot easier then attempting to figure what G++ is actually complaining about with these sources.
I was hoping to get something useful going quickly, no such luck.
The open source Spin compiler is very easy to build. Never failed for me on x86 or Pi.
$ svn checkout [URL]http://open-source-spin-compiler.googlecode.com/svn/[/URL] open-source-spin-compiler-read-only
$ cd open-source-spin-compiler-read-only/
$ make
It takes less time to build than writing this post.
(Looks like Heater answered while I was typing)...
Do these steps work (I assume on your Raspberry Pi)?
1. If you need to run subversion (svn) on the Raspberry Pi to get the sources do "sudo apt-get install -y subversion"
2. To get the latest sources checkout to you local source directory with "svn checkout http://open-source-spin-compiler.googlecode.com/svn/ open-source-spin-compiler-read-only"
3. cd to the new directory: "open-source-spin-compiler-read-only"
4. Then, run: "make all"
5. Step #4 should have created the executable: "openspin". You can test it with the command "./openspin". That should show you openspin's options...
6. Copy the openspin executable to "/opt/parallax/bin/"
7. In SImple IDE, mod the Spin Compiler option in the Properties window to "/opt/parallax/bin/openspin" (see attached image)
8 Create a new .spin file or open an existing one
RESULT: should be able to compile with openspin compiler
Ok interesting. The SVN copy works with out any problem. I originally attempted with the zipped copy from the google code page, as I have found that many projects have a easier to compile source in there distrobution archives than they have in there subversion/cvs/git repos.
I now know to use the subversion copy of OpenSpin. Does any one know what the issue is with the download page source archive?
Nobody cares. This is an open source world, we grab the latest code and compile it. That way if there is an issue we can report it straight away against the latest code updates in the repo and everyone knows what we are talking about.
I originally attempted with the zipped copy from the google code page, as I have found that many projects have a easier to compile source in there distribution archives than they have in there subversion/cvs/git repos.
Probably true for some cases, but I've found propgcc, SimpleIDE and openspin sources archives to be trivial to compile. Folks behind these projects have done a great job!
Except in this case davidsauders is right. The source code ZIP file available on Google code does not compile (sourcecode-r53.zip). Exactly as he describes.
It is missing a definition of PATH_MAX.
I added
#include <limits.h>
to openspin.cpp and then it compiled fine.
Probably a quicker solution than rewriting it all C89:)
That was my point... The source archive (i.e. code repository, NOT the ZIP) does compile!
My comment was to davidsauder's post where he stated "Ok interesting. The SVN copy works with out any problem... I originally attempted with the zipped copy from the google code page, as I have found that many projects have a easier to compile source in there distribution archives than they have in there subversion/cvs/git repos", not to yours
Is it possible to get a more-recent version of the sources in a ZIP distro? Or, is this something that you've got in-progress and we should jut wait for? :cool:
The zip of the source is not that old and it does compile on some platforms. The PATH_MAX issue is because, sadly and annoyingly, some platforms/compilers define it differently and in different places. I had updated source in svn but not made a new zip (I have to do that manually). I'll update the zip when I do my next update which isn't ready yet.
Also, fair warning, google is going to stop allowing us to put new downloads on google code in the future. It'll just be the source and no build exes or source zips. We'll have to work out some other arrangement for providing build exe's and source zips.
Now that I am able to compile it with no trouble would there be any objection to me making some modifications to allow it to be compiled as a RISC OS module that exports the *commands? The changes should be fairly miner and could be done without breaking its compatability with Linux and windows.
Mostly redifine the Path seperater and the file extension handling, I did not see anything else that is OS Specific in there.
It's "open source". It's published under the MIT license. You can do whatever you like with it.
If the changes are sensible and don't impact other platforms Roy might even like to fold them into his repository.
Ok I just wanted to make sure that no one would be opposed to the idea. I am aware that there is no issue as far as the license goes.
I will probably have to use the RISC OS version of GCC as I do not think that it will compile correctly with Norcroft with out significant modification, though If I can get it to compile with Norcroft with out breaking it on other platforms I will.
I will probably have to use the RISC OS version of GCC as I do not think that it will compile correctly with Norcroft with out significant modification, though If I can get it to compile with Norcroft with out breaking it on other platforms I will.
Fewer the changes, the better.
Once you make significant modifications to code, it is difficult to merge back if at all possible. If there are updates, you get to resolve any merge conflicts in your repository.
Yes it does compile with Norcroft. Though it is not yet running.
I was surprised that it even compiled with Norcroft, as the C++ compiler is not as up to date as the C compiler by a long shot. I am still sorting out the problems. I think that the C++ compiler in Norcroft uses a CFront implementation so there is a noticable limit to what can be compiled that way. I do know that most C++ programs are a pain to port, even if they only use the standard libraries due to the limitations of the C++ compiler.
Though it will be very nice to end up with a good working Spin + PASM compiler + assembler that will run on RISC OS. And knowing that it is 100% compatible with Chips makes it that much better.
If you can get that working then you will need a loader. There is a loader in C in the propgcc package. It should only need a new serial port interface module to be written for RISCOS.
If you can get that working then you will need a loader. There is a loader in C in the propgcc package. It should only need a new serial port interface module to be written for RISCOS.
As long as it is easy enough to do with the FTDI serial module in RISC OS. I am using the serial pins for other things.
As long as it shows up as a serial port in the OS you can use normal OS API functionality to drive it. There is nothing special about the way the loader uses serial.
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.
Comments
#define PATH_MAX 256
needs to be moved outside of the '#if defined(WIN32)' to build under Ubuntu in openspin.cpp
I have an update coming soon (maybe this weekend) that changes that. It handles it in a different way that should work across more platforms.
Others,
Just a heads up, this next update is going to do a lot of rearranging of the code (including splitting some stuff out into it's own files). It's something that's been needed for a while, and I finally got sick of the state it was in.
Also, it will *not* include the @@@ feature yet. That one turned out to be a more significant nut to crack because of how the compiler works, so I've shelved it for a bit in order to get some stuff done that Parallax requested. It'll get in there eventually.
When did Chip release the source for the Spin compiler? And where is it?
Ah ok. Thank you I almost thought that I was loosing it.
That makes sense.
Darned Rasbian uses a UK keyboard layout after selecting US 104 key keyboard.
After spending a little time attempting to at least get this thing to compile on Linux ARMv6 I am having zero luck. It does not help that it is C++ not C.
G++ (GCC C++ Compiler) keeps telling me that identifiers that are global to the source module are not declared in the current scope. Five languages that I really hate: C++, Java, VB, D, and C#, they are impossible to understand unless you are the programmer of origin and you commented the source well, and it has been less than 1 week since you created the source files.
OO in pure C is easier than mixed OO and procedural in C++.
I will attempt to translate these into C89 and compile that, a lot easier then attempting to figure what G++ is actually complaining about with these sources.
I was hoping to get something useful going quickly, no such luck.
It takes less time to build than writing this post.
(Looks like Heater answered while I was typing)...
Do these steps work (I assume on your Raspberry Pi)?
dgately
I now know to use the subversion copy of OpenSpin. Does any one know what the issue is with the download page source archive?
Nobody cares. This is an open source world, we grab the latest code and compile it. That way if there is an issue we can report it straight away against the latest code updates in the repo and everyone knows what we are talking about.
Probably true for some cases, but I've found propgcc, SimpleIDE and openspin sources archives to be trivial to compile. Folks behind these projects have done a great job!
dgately
It is missing a definition of PATH_MAX.
I added to openspin.cpp and then it compiled fine.
Probably a quicker solution than rewriting it all C89:)
That was my point... The source archive (i.e. code repository, NOT the ZIP) does compile!
My comment was to davidsauder's post where he stated "Ok interesting. The SVN copy works with out any problem... I originally attempted with the zipped copy from the google code page, as I have found that many projects have a easier to compile source in there distribution archives than they have in there subversion/cvs/git repos", not to yours
dgately
Problem is that David was originally annoyed because the zip package does not compile out of the box.
I was surprised so I had to check it for myself.
That zip must be really old because I have not had a problem with the svn check out for a year or so.
Ah well.
Is it possible to get a more-recent version of the sources in a ZIP distro? Or, is this something that you've got in-progress and we should jut wait for? :cool:
Thanks,
dgately
Also, fair warning, google is going to stop allowing us to put new downloads on google code in the future. It'll just be the source and no build exes or source zips. We'll have to work out some other arrangement for providing build exe's and source zips.
Roy
Just a suggestion:)
Mostly redifine the Path seperater and the file extension handling, I did not see anything else that is OS Specific in there.
If the changes are sensible and don't impact other platforms Roy might even like to fold them into his repository.
I will probably have to use the RISC OS version of GCC as I do not think that it will compile correctly with Norcroft with out significant modification, though If I can get it to compile with Norcroft with out breaking it on other platforms I will.
dgately
Fewer the changes, the better.
Once you make significant modifications to code, it is difficult to merge back if at all possible. If there are updates, you get to resolve any merge conflicts in your repository.
math.h
string.h
stdlib.h
stdio.h
errno.h
So if Norcroft is reasonably up to the C++ standards it should compile out of the box with no changes.
There may be issues with those weird file paths in RISC OS but I suspect that is no big deal.
I was surprised that it even compiled with Norcroft, as the C++ compiler is not as up to date as the C compiler by a long shot. I am still sorting out the problems. I think that the C++ compiler in Norcroft uses a CFront implementation so there is a noticable limit to what can be compiled that way. I do know that most C++ programs are a pain to port, even if they only use the standard libraries due to the limitations of the C++ compiler.
Though it will be very nice to end up with a good working Spin + PASM compiler + assembler that will run on RISC OS. And knowing that it is 100% compatible with Chips makes it that much better.
If you can get that working then you will need a loader. There is a loader in C in the propgcc package. It should only need a new serial port interface module to be written for RISCOS.
As long as it is easy enough to do with the FTDI serial module in RISC OS. I am using the serial pins for other things.
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.