RossH, thanks for your previous patch file, sorry for the super long delay in getting it applied, modified, and tested. I, also, had to fix a few things to make it produce proper binary output matching the original spin compiler. If you have more changes I can include, then just send 'em to me.
Thanks Roy.
I was just about to release a new version of Catalina that uses openspin exclusively. I'll hang off for a few more days until I've had a chance to review your recent changes.
"A static library is a library of code that can be linked into a binary that will, eventually, be dynamically linked to the system libraries and frameworks."
Who came up with this definition?
"When I use a word," Humpty Dumpty said, in a rather scornful tone, "it means just what I choose it to mean - neither more nor less." "The question is," said Alice, "whether you can make words mean so many different things." "The question is," said Humpty Dumpty, "which is to be master - that's all."
Through the Looking Glass (aka the Apple Marketing Manual).
"A static library is a library of code that can be linked into a binary that will, eventually, be dynamically linked to the system libraries and frameworks."
Who came up with this definition?
In the Linux/Unix world there are statically and dynamically linked (shared) libraries.
Static libraries are linked into your program at build time to create an executable binary file.
Dynamic libraries are loaded and linked at run time. A single dynamic lib may be loaded once and used by many executables.
A single program is said to be "statically linked" if it use no shared libraries. It is said to be "dynamically linked" if it uses any shared libraries.
I'm sure Windows does something similar.
Isn't Humpty Dumpty...err...Apple using the term "static" the same way?
However, when I test the compiler within SimpleIDE, it chokes on the Library/Include option... Apparently, when the compiler is named "openspin" SimpleIDE uses "-L" for directory inclusion, rather than "-I".
Of course, the older version of the the compiler was named "spin" and it worked!
To test my theory, I renamed the compiler from "openspin" to "spin" and it compiles my spin project successfully!
Here's a build with "openspin":
[SIZE=4]Project Directory: /Users/myHome/ParallaxCode/Stingray/StingrayTest/stingrayRC/[/SIZE][SIZE=4]
[/SIZE]
[SIZE=4]openspin -b [B][U]-L[/U][/B] /Users/myHome/ParallaxCode/SpinObjects/ stingrayRC.spin[/SIZE]
[SIZE=4]usage: openspin[/SIZE]
[SIZE=4] [ -h ] display this help[/SIZE]
[SIZE=4] [ -I <path> ] add a directory to the include path[/SIZE]
[SIZE=4] [ -o <path> ] output filename[/SIZE]
[SIZE=4] [ -b ] output binary file format[/SIZE]
[SIZE=4] [ -c ] output only DAT sections[/SIZE]
[SIZE=4] [ -d ] dump out doc mode[/SIZE]
[SIZE=4] [ -e ] output eeprom file format[/SIZE]
[SIZE=4] [ -q ] quiet mode (suppress banner and non-error text)[/SIZE]
[SIZE=4] [ -v ] verbose output[/SIZE]
[SIZE=4] [ -p ] use preprocessor[/SIZE]
[SIZE=4] [ -a ] use alternative preprocessor rules[/SIZE]
[SIZE=4] [ -D <define> ] add a define (must have -p before any of these)[/SIZE]
[SIZE=4] [ -M <size> ] size of eeprom (up to 16777216 bytes)[/SIZE]
[SIZE=4] <name.spin> spin file to compile[/SIZE]
[SIZE=4]Propeller Spin/PASM Compiler 'OpenSpin' (c)2012-2013 Parallax Inc. DBA Parallax Semiconductor.[/SIZE]
[SIZE=4]Compiled on Aug 20 2013
[/SIZE]
Here's a build with "openspin" renamed to "spin"
[SIZE=4]Project Directory: /Users/myHome/ParallaxCode/Stingray/StingrayTest/stingrayRC/[/SIZE]
[SIZE=4]spin [B][U]-I[/U][/B] /Users/myHome/ParallaxCode/SpinObjects/ stingrayRC.spin[/SIZE]
[SIZE=4]Propeller Spin/PASM Compiler 'OpenSpin' (c)2012-2013 Parallax Inc. DBA Parallax Semiconductor.[/SIZE]
[SIZE=4]Compiled on Aug 20 2013[/SIZE]
[SIZE=4]Compiling stingrayRC.spin...[/SIZE]
[SIZE=4]Done.[/SIZE]
[SIZE=4]Program size is 9988 bytes[/SIZE]
Perhaps Jazzed can set us straight on why SimpleIDE uses the "-L" for openspin (it's using the C code "-L" library path option) when the spin compiler is named "openspin"...
I could change the openspin command line options to line up better with BSTC's. Would make the SimpleIDE code simpler to not have as many changes based on which compiler it's using.
Let's see what Steve says.
Having similar options to bstc would certainly make life a bit easier for those who like to use the command line occationally or use make files or other scrpted builds and tools.
A single program is said to be "statically linked" if it use no shared libraries. It is said to be "dynamically linked" if it uses any shared libraries.
That's certainly how I see it.
To me Humpty Dumpty's statement parses differently with the phrase: "that will, eventually, be dynamically linked" ....
Of course it is possible to include the same source code in a dynamic and a static library. However a program that has static libraries linked does not require dynamic libraries.
If you want all libraries to be dynamically linked, that's fine, but there is no guarantee that you get what you really want across versions unless code is "statically linked" or handled by a package manager. The primary advantages of dynamic linking are 1) smaller possible aggregate system size, and 2) being able to use LGPL libraries.
A program can be built from a combination of static and shared libraries (with different codes) so I parsed Humpty's statement as meaning that a static library can be linked to a program producing a binary lump that in turn will end up being linked to dynamic libraries at run time.
Lot's of BSTC's command line arguments make sense. I don't think we need to follow it verbatim though.
Here are OpenSpin's command line options:
Propeller Spin/PASM Compiler (c)2012 Parallax Inc. DBA Parallax Semiconductor.
Compiled on Jun 21 2013
usage: spin
[ -I <path> ] add a directory to the include path
[ -o <path> ] output filename
[ -c ] output only DAT sections
[ -d ] dump out doc mode
[ -q ] quiet mode (suppress banner and non-error text)
[ -v ] verbose output
[ -p ] use preprocessor
[ -D <define> ] add a define (must have -p before any of these)
<name.spin> spin file to compile
Comparing this to Bstc command line arguments or preferred behaviour:
The OpenSpin library directory specifier should be either -L or -I.
Argument -p should not be required to enable the pre-processor.
Bstc does not require ".spin" while OpenSpin does ... it's ok to require ".spin".
Bstc supports -a to make an archive ... making the archive is not important, but having a fully qualified list of sources would be very useful.
Bstc can produce and download a .eeprom file by specifying -e. It is not important.
Bstc requires -b to make a .binary ... I'm very happy OpenSpin does not require it.
Bstc supports -d to specify a port ... OpenSpin doesn't need to download.
Bstc supports -l for list file generation. This is a useful debugging feature, but not necessary at the moment.
Bstc supports dead code pruning and other optimizations ... eventually we need that in OpenSpin.
We need OpenSpin to support the @@@ operator to fix global HUB addresses.
OpenSpin seems to have size reporting problems when using -c to extract .dat sections.
I've encountered various preprocessor issues with openspin.
I need a tree dump for building the spin dependencies list so the IDE does not have to parse the spin code. A fully qualified path/file name for each file used would be best for IDE usage (maybe enabled with a flag).
Here is a dump of what we get today.
sh-3.1$ bstc BMADebugger_Demo.spin
Brads Spin Tool Compiler v0.15.4-pre3 - Copyright 2008,2009 All rights reserved
Compiled for i386 Win32 at 19:57:58 on 2010/01/15
Loading Object BMADebugger_Demo
Loading Object BMAdebugger
Loading Object PASMstub
Loading Object BMAopcodes
Loading Object BMAutility
Loading Object FullDuplexSingleton
Program size is 7556 longs
Compiled 1041 Lines of Code in 0.015 Seconds
sh-3.1$ spin BMADebugger_Demo.spin
Propeller Spin/PASM Compiler (c)2012 Parallax Inc. DBA Parallax Semiconductor.
Compiled on Jun 21 2013
Compiling BMADebugger_Demo.spin...
Done.
Program size is 7960 bytes
sh-3.1$
Steve:
The -e for eeprom makes an eeprom (32KB) file which can be loaded into eeprom. I have used this in my PropOS with a PROGRAM command to load into the lower or upper 32KB of the eeprom. I don't use binaries because they are smaller and I was planning to use this as to program just a section of code into the eeprom.
Therefore I am interested in why you think the eeprom output is not required (for later at least)?
I guess it depends on whether loading a .binary file zeroes the unprogrammed bytes when used to write the EEPROM. (Frankly, I just don't remember.) If it does, an .eeprom loader is probably superfluous. But if not, you really need to deal with .eeprom files.
In any event, it's not clear to me why the latter exists at all. An Intel .hex file might have been a better, more universally-accepted choice -- especially when EEPROMs are to be programmed externally.
Steve, I noticed your posting was still using the previous build of OpenSpin. Since there are now several new options include -e for eeproms.
In the next build I will make it so that you can use -L or -I for the lib/include path option. I'll also invert the -p option so that it turns off the preprocessor, and it will be on by default. I'll also, finally, get the options working to output the archive file list and object tree list.
Doing some tests with BSTC and OpenSpin related to the program size output. In my test case the compiled binary file is 7016 bytes in size on disk (OS reported). BSTC reports the size at 7012 longs. and OpenSpin reports the size as 7436 bytes. Obviously, both are wrong.
I figured out that OpenSpin was reporting the size of the program + the size of var space which isn't in the binary file output. I've fixed OpenSpin to now output the proper binary size in bytes (so in my test case it says 7016 bytes).
BSTC seems to be reporting the size of the program minus the first 4 bytes (which is the clock config stuff), but it's bytes even though it says longs.
Could I ask that a link also be placed in the first post for SimpleIDE too please (both the thread and download preferred). They are going to go hand-in-hand.
I think we are now at a point where I am interested in switching to SimpleIDE + OpenSpin.
Just for reference, I use PropTool, bst, homespun in that order as my code requires increased complexity. It will be much nicer to stay in one environment - thanks for your efforts Roy & Steve, etc.
Couldn't sleep, so I did some more work on this, see first post for addition details.
Roy
Roy,
I'm getting errors compiling open-spin on Mac OS X with r53. Does seem to point to the changes between r52 & r53... Fix looks simple!
[myHome@dgate ~/source]$svn checkout http://open-source-spin-compiler.googlecode.com/svn/ open-source-spin-compiler-read-only
A open-source-spin-compiler-read-only/PropellerCompiler
A open-source-spin-compiler-read-only/PropellerCompiler/PropellerCompiler.cpp
A open-source-spin-compiler-read-only/PropellerCompiler/SymbolEngine.h
A open-source-spin-compiler-read-only/PropellerCompiler/PropellerCompilerInternal.h
A open-source-spin-compiler-read-only/PropellerCompiler/BlockNestStackRoutines.cpp
A open-source-spin-compiler-read-only/PropellerCompiler/ErrorStrings.cpp
A open-source-spin-compiler-read-only/PropellerCompiler/PropellerCompiler.h
A open-source-spin-compiler-read-only/PropellerCompiler/ErrorStrings.h
A open-source-spin-compiler-read-only/PropellerCompiler/CompileExpression.cpp
A open-source-spin-compiler-read-only/PropellerCompiler/StringConstantRoutines.cpp
A open-source-spin-compiler-read-only/PropellerCompiler/Utilities.cpp
A open-source-spin-compiler-read-only/PropellerCompiler/DistillObjects.cpp
A open-source-spin-compiler-read-only/PropellerCompiler/CompileDatBlocks.cpp
A open-source-spin-compiler-read-only/PropellerCompiler/Utilities.h
A open-source-spin-compiler-read-only/PropellerCompiler/PropellerCompiler.vcproj
A open-source-spin-compiler-read-only/PropellerCompiler/ExpressionResolver.cpp
A open-source-spin-compiler-read-only/PropellerCompiler/Elementizer.cpp
A open-source-spin-compiler-read-only/PropellerCompiler/CompileUtilities.cpp
A open-source-spin-compiler-read-only/PropellerCompiler/InstructionBlockCompiler.cpp
A open-source-spin-compiler-read-only/PropellerCompiler/Elementizer.h
A open-source-spin-compiler-read-only/PropellerCompiler/CompileUtilities.h
A open-source-spin-compiler-read-only/PropellerCompiler/CompileInstruction.cpp
A open-source-spin-compiler-read-only/PropellerCompiler/SymbolEngine.cpp
A open-source-spin-compiler-read-only/PropellerCompiler/Makefile
A open-source-spin-compiler-read-only/wiki
A open-source-spin-compiler-read-only/wiki/CurrentState.wiki
A open-source-spin-compiler-read-only/openspin.sln
A open-source-spin-compiler-read-only/SpinSource
A open-source-spin-compiler-read-only/SpinSource/flexbuf.h
A open-source-spin-compiler-read-only/SpinSource/preprocess.c
A open-source-spin-compiler-read-only/SpinSource/preprocess.h
A open-source-spin-compiler-read-only/SpinSource/openspin.cpp
A open-source-spin-compiler-read-only/SpinSource/flexbuf.c
A open-source-spin-compiler-read-only/SpinSource/SpinSource.vcproj
A open-source-spin-compiler-read-only/PropellerCompiler.sln
A open-source-spin-compiler-read-only/Makefile
Checked out revision 53.
[myHome@dgate ~/source]$ cd open-source-spin-compiler-read-only/
[myHome@dgate ~/source/open-source-spin-compiler-read-only]$ make all
make -C PropellerCompiler all
g++ -DGCC -Wall -g -o BlockNestStackRoutines.o -c BlockNestStackRoutines.cpp
g++ -DGCC -Wall -g -o CompileDatBlocks.o -c CompileDatBlocks.cpp
g++ -DGCC -Wall -g -o CompileExpression.o -c CompileExpression.cpp
g++ -DGCC -Wall -g -o CompileInstruction.o -c CompileInstruction.cpp
g++ -DGCC -Wall -g -o CompileUtilities.o -c CompileUtilities.cpp
g++ -DGCC -Wall -g -o DistillObjects.o -c DistillObjects.cpp
g++ -DGCC -Wall -g -o Elementizer.o -c Elementizer.cpp
g++ -DGCC -Wall -g -o ErrorStrings.o -c ErrorStrings.cpp
g++ -DGCC -Wall -g -o ExpressionResolver.o -c ExpressionResolver.cpp
g++ -DGCC -Wall -g -o InstructionBlockCompiler.o -c InstructionBlockCompiler.cpp
g++ -DGCC -Wall -g -o StringConstantRoutines.o -c StringConstantRoutines.cpp
g++ -DGCC -Wall -g -o SymbolEngine.o -c SymbolEngine.cpp
g++ -DGCC -Wall -g -o Utilities.o -c Utilities.cpp
Utilities.cpp: In function bool GetFilename(int&, int&):
Utilities.cpp:491: warning: comparison is always false due to limited range of data type
g++ -DGCC -Wall -g -o PropellerCompiler.o -c PropellerCompiler.cpp
ar rs libopenspin.a BlockNestStackRoutines.o CompileDatBlocks.o CompileExpression.o CompileInstruction.o CompileUtilities.o DistillObjects.o Elementizer.o ErrorStrings.o ExpressionResolver.o InstructionBlockCompiler.o StringConstantRoutines.o SymbolEngine.o Utilities.o PropellerCompiler.o
ar: creating archive libopenspin.a
g++ -o openspin -DGCC -Wall -g SpinSource/openspin.cpp SpinSource/flexbuf.c SpinSource/preprocess.c PropellerCompiler/libopenspin.a
SpinSource/openspin.cpp:76: error: PATH_MAX was not declared in this scope
SpinSource/openspin.cpp:79: error: PATH_MAX was not declared in this scope
SpinSource/openspin.cpp: In function const char* MakePath(PathEntry*, const char*):
SpinSource/openspin.cpp:83: error: lastfullpath was not declared in this scope
SpinSource/openspin.cpp: In function FILE* OpenFileInPath(const char*, const char*):
SpinSource/openspin.cpp:142: error: lastfullpath was not declared in this scope
SpinSource/openspin.cpp:149: error: filesAccessed was not declared in this scope
SpinSource/openspin.cpp:149: error: lastfullpath was not declared in this scope
SpinSource/openspin.cpp: In function int main(int, char**):
SpinSource/openspin.cpp:507: error: filesAccessed was not declared in this scope
SpinSource/openspin.cpp:516: error: filesAccessed was not declared in this scope
make: *** [all] Error 1
From that point, the other var's declarations seemed to get missed, as well.
I searched for 'filesaccessed' in the diff for r53 and do see that this is a new var for this revision. Looks like it does get declared on line line 79 of openspin.cpp, but the compiler is not seeing the declaration later in the same source file.
To test: I moved the line (57) "#define PATH_MAX 256" back above line (56) "#if defined(WIN32)" and it compiles once again...
dgately,
Sorry about that, I made that change because on linux is appears that PATH_MAX is defined already by the stdlib inlude, and I had assumed it would be the same on OSX. The issue is that if PATH_MAX is some value larger than 256 in the linux includes, then it's possible that the call to realpath() could overflow our buffer. I'll work out a fix for this tonight when I get home.
dgately,
I've put up a small change that should build on OSX now. I didn't do new downloads of the exe or source for this one since it only matters to OSX people who need to build themselves anyway. So go get r54 and see if it builds properly on OSX now.
dgately,
I've put up a small change that should build on OSX now. I didn't do new downloads of the exe or source for this one since it only matters to OSX people who need to build themselves anyway. So go get r54 and see if it builds properly on OSX now.
@Roy: I noticed that saving the DAT section of a binary always rounds up to 4n, is that intentional? bstc only ever extracted the real size (e.g. 1022 bytes).
kuroneko,
First of all, thanks for questioning the DAT only feature, because I found a bug in there that would cause it to output incorrectly depending on how many OBJ references you had in the top object. It was actually only correct if the top object had exactly one OBJ reference. If it had none or more than one, then the DAT only output was wrong. I've changed code to fix this.
I've also found that if you have a FIT at the end of your DAT section, my code was padding the size at that point to a multiple of 4 bytes. This is what I believe you are seeing in your case. I've also put in a code fix for this.
I haven't done a full build with these fixes yet. I'll do a build later tonight (Saturday night).
kuroneko,
Ok, I undid part of that change, check the new source. 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.
Interestingly, none of the 1462 OBEX files I tested with have a label on the FIT directive line, so they all compiled successfully. It's good to have someone like you that tries all the weird things that no one else does and catches these kinds of thing.
Comments
Thanks Roy.
I was just about to release a new version of Catalina that uses openspin exclusively. I'll hang off for a few more days until I've had a chance to review your recent changes.
Ross.
"When I use a word," Humpty Dumpty said, in a rather scornful tone, "it means just what I choose it to mean - neither more nor less."
"The question is," said Alice, "whether you can make words mean so many different things."
"The question is," said Humpty Dumpty, "which is to be master - that's all."
Through the Looking Glass (aka the Apple Marketing Manual).
I've updated the Makefiles to exclude the -static option for OSX, can you please get the latest and try building on your Mac?
In the Linux/Unix world there are statically and dynamically linked (shared) libraries.
Static libraries are linked into your program at build time to create an executable binary file.
Dynamic libraries are loaded and linked at run time. A single dynamic lib may be loaded once and used by many executables.
A single program is said to be "statically linked" if it use no shared libraries. It is said to be "dynamically linked" if it uses any shared libraries.
I'm sure Windows does something similar.
Isn't Humpty Dumpty...err...Apple using the term "static" the same way?
Wikipedia would think so as well. http://en.wikipedia.org/wiki/Static_library
OK, built the latest sources from: http://code.google.com/p/open-source-spin-compiler/source/checkout
However, when I test the compiler within SimpleIDE, it chokes on the Library/Include option... Apparently, when the compiler is named "openspin" SimpleIDE uses "-L" for directory inclusion, rather than "-I".
Of course, the older version of the the compiler was named "spin" and it worked!
To test my theory, I renamed the compiler from "openspin" to "spin" and it compiles my spin project successfully!
Here's a build with "openspin":
Here's a build with "openspin" renamed to "spin"
Perhaps Jazzed can set us straight on why SimpleIDE uses the "-L" for openspin (it's using the C code "-L" library path option) when the spin compiler is named "openspin"...
Thanks,
dgately
buildspin.cpp after line 61:
[COLOR=#808000]if[/COLOR][COLOR=#000000](([/COLOR][COLOR=#000000]comp[/COLOR][COLOR=#000000].[/COLOR][COLOR=#000000]compare[/COLOR][COLOR=#000000]([/COLOR][COLOR=#008000]"spin"[/COLOR][COLOR=#000000],[/COLOR][COLOR=#800080]Qt[/COLOR][COLOR=#000000]::[/COLOR][COLOR=#800080]CaseInsensitive[/COLOR][COLOR=#000000])[/COLOR][COLOR=#000000]==[/COLOR][COLOR=#000080]0[/COLOR][COLOR=#000000])[/COLOR][COLOR=#000000]||[/COLOR] [COLOR=#000000] ([/COLOR][COLOR=#000000]comp[/COLOR][COLOR=#000000].[/COLOR][COLOR=#000000]compare[/COLOR][COLOR=#000000]([/COLOR][COLOR=#008000]"spin.exe"[/COLOR][COLOR=#000000],[/COLOR][COLOR=#800080]Qt[/COLOR][COLOR=#000000]::[/COLOR][COLOR=#800080]CaseInsensitive[/COLOR][COLOR=#000000])[/COLOR][COLOR=#000000]==[/COLOR][COLOR=#000080]0[/COLOR][COLOR=#000000]))[/COLOR][COLOR=#000000]{[/COLOR] [COLOR=#008000] // Roy's compiler always makes a .binary[/COLOR] [COLOR=#808000] if[/COLOR][COLOR=#000000]([/COLOR][COLOR=#000000]libdir[/COLOR][COLOR=#000000].[/COLOR][COLOR=#000000]exists[/COLOR][COLOR=#000000]([/COLOR][COLOR=#800000]properties[/COLOR][COLOR=#000000]->[/COLOR][COLOR=#000000]getSpinLibraryStr[/COLOR][COLOR=#000000]()))[/COLOR][COLOR=#000000]{[/COLOR] [COLOR=#000000] args[/COLOR][COLOR=#000000].[/COLOR][COLOR=#000000]append[/COLOR][COLOR=#000000]([/COLOR][COLOR=#008000]"-I"[/COLOR][COLOR=#000000]); [/COLOR][SIZE=4][COLOR=#ff0000][B]<==== "-I"[/B][/COLOR][/SIZE] [COLOR=#000000] args[/COLOR][COLOR=#000000].[/COLOR][COLOR=#000000]append[/COLOR][COLOR=#000000]([/COLOR][COLOR=#800000]properties[/COLOR][COLOR=#000000]->[/COLOR][COLOR=#000000]getSpinLibraryStr[/COLOR][COLOR=#000000]());[/COLOR] [COLOR=#000000] }[/COLOR] [COLOR=#000000]}[/COLOR] [COLOR=#808000]else[/COLOR][COLOR=#000000]{[/COLOR] [COLOR=#008000]/* other compiler options */[/COLOR] [COLOR=#808000]if[/COLOR][COLOR=#000000]([/COLOR][COLOR=#800000]projectOptions[/COLOR][COLOR=#000000]->[/COLOR][COLOR=#000000]getSpinCompOptions[/COLOR][COLOR=#000000]().[/COLOR][COLOR=#000000]length[/COLOR][COLOR=#000000]())[/COLOR][COLOR=#000000]{[/COLOR] [COLOR=#800080] QStringList[/COLOR][COLOR=#000000]complist[/COLOR][COLOR=#000000]=[/COLOR][COLOR=#800000]projectOptions[/COLOR][COLOR=#000000]->[/COLOR][COLOR=#000000]getSpinCompOptions[/COLOR][COLOR=#000000]().[/COLOR][COLOR=#000000]split[/COLOR][COLOR=#000000]([/COLOR][COLOR=#008000]" "[/COLOR][COLOR=#000000],[/COLOR][COLOR=#800080]QString[/COLOR][COLOR=#000000]::[/COLOR][COLOR=#800080]SkipEmptyParts[/COLOR][COLOR=#000000]);[/COLOR] [COLOR=#808000] foreach[/COLOR][COLOR=#000000]([/COLOR][COLOR=#800080]QString[/COLOR][COLOR=#000000]compopt[/COLOR][COLOR=#000000],[/COLOR][COLOR=#000000]complist[/COLOR][COLOR=#000000])[/COLOR][COLOR=#000000]{[/COLOR] [COLOR=#000000] args[/COLOR][COLOR=#000000].[/COLOR][COLOR=#000000]append[/COLOR][COLOR=#000000]([/COLOR][COLOR=#000000]compopt[/COLOR][COLOR=#000000]);[/COLOR] [COLOR=#000000] }[/COLOR] [COLOR=#000000]}[/COLOR] [COLOR=#008000]// BSTC needs to be told to make a .binary[/COLOR] [COLOR=#000000]args[/COLOR][COLOR=#000000].[/COLOR][COLOR=#000000]append[/COLOR][COLOR=#000000]([/COLOR][COLOR=#008000]"-b"[/COLOR][COLOR=#000000]);[/COLOR] [COLOR=#808000]if[/COLOR][COLOR=#000000]([/COLOR][COLOR=#000000]libdir[/COLOR][COLOR=#000000].[/COLOR][COLOR=#000000]exists[/COLOR][COLOR=#000000]([/COLOR][COLOR=#800000]properties[/COLOR][COLOR=#000000]->[/COLOR][COLOR=#000000]getSpinLibraryStr[/COLOR][COLOR=#000000]()))[/COLOR][COLOR=#000000]{[/COLOR] [COLOR=#000000] args[/COLOR][COLOR=#000000].[/COLOR][COLOR=#000000]append[/COLOR][COLOR=#000000]([/COLOR][COLOR=#008000]"-L"[/COLOR][COLOR=#000000]); [/COLOR][SIZE=4][COLOR=#ff0000][B]<==== "-L"[/B][/COLOR][/SIZE] [COLOR=#000000] args[/COLOR][COLOR=#000000].[/COLOR][COLOR=#000000]append[/COLOR][COLOR=#000000]([/COLOR][COLOR=#800000]properties[/COLOR][COLOR=#000000]->[/COLOR][COLOR=#000000]getSpinLibraryStr[/COLOR][COLOR=#000000]());[/COLOR] [COLOR=#000000] } [/COLOR][COLOR=#000000]} [/COLOR]SimpleIDE will just need additional comp.compares for "openspin" and "openspin.exe"
dgately
I could change the openspin command line options to line up better with BSTC's. Would make the SimpleIDE code simpler to not have as many changes based on which compiler it's using.
Let's see what Steve says.
To me Humpty Dumpty's statement parses differently with the phrase: "that will, eventually, be dynamically linked" ....
Of course it is possible to include the same source code in a dynamic and a static library. However a program that has static libraries linked does not require dynamic libraries.
If you want all libraries to be dynamically linked, that's fine, but there is no guarantee that you get what you really want across versions unless code is "statically linked" or handled by a package manager. The primary advantages of dynamic linking are 1) smaller possible aggregate system size, and 2) being able to use LGPL libraries.
Ah well.
Here are OpenSpin's command line options:
Propeller Spin/PASM Compiler (c)2012 Parallax Inc. DBA Parallax Semiconductor. Compiled on Jun 21 2013 usage: spin [ -I <path> ] add a directory to the include path [ -o <path> ] output filename [ -c ] output only DAT sections [ -d ] dump out doc mode [ -q ] quiet mode (suppress banner and non-error text) [ -v ] verbose output [ -p ] use preprocessor [ -D <define> ] add a define (must have -p before any of these) <name.spin> spin file to compileThe OpenSpin library directory specifier should be either -L or -I.
Argument -p should not be required to enable the pre-processor.
Bstc does not require ".spin" while OpenSpin does ... it's ok to require ".spin".
Bstc supports -a to make an archive ... making the archive is not important, but having a fully qualified list of sources would be very useful.
Bstc can produce and download a .eeprom file by specifying -e. It is not important.
Bstc requires -b to make a .binary ... I'm very happy OpenSpin does not require it.
Bstc supports -d to specify a port ... OpenSpin doesn't need to download.
Bstc supports -l for list file generation. This is a useful debugging feature, but not necessary at the moment.
Bstc supports dead code pruning and other optimizations ... eventually we need that in OpenSpin.
We need OpenSpin to support the @@@ operator to fix global HUB addresses.
OpenSpin seems to have size reporting problems when using -c to extract .dat sections.
I've encountered various preprocessor issues with openspin.
I need a tree dump for building the spin dependencies list so the IDE does not have to parse the spin code. A fully qualified path/file name for each file used would be best for IDE usage (maybe enabled with a flag).
Here is a dump of what we get today.
... can be linked to a program producing a binary lump that in turn can end up being linked to dynamic libraries at run time.
Subtle difference. At least we don't have to parse it backwards.
The -e for eeprom makes an eeprom (32KB) file which can be loaded into eeprom. I have used this in my PropOS with a PROGRAM command to load into the lower or upper 32KB of the eeprom. I don't use binaries because they are smaller and I was planning to use this as to program just a section of code into the eeprom.
Therefore I am interested in why you think the eeprom output is not required (for later at least)?
If you need .eeprom, then I'm sure it will be considered.
My lengthy post was really just to start a conversation about these kind of things so that we have a good idea of what the needs are.
I guess it depends on whether loading a .binary file zeroes the unprogrammed bytes when used to write the EEPROM. (Frankly, I just don't remember.) If it does, an .eeprom loader is probably superfluous. But if not, you really need to deal with .eeprom files.
In any event, it's not clear to me why the latter exists at all. An Intel .hex file might have been a better, more universally-accepted choice -- especially when EEPROMs are to be programmed externally.
-Phil
In the next build I will make it so that you can use -L or -I for the lib/include path option. I'll also invert the -p option so that it turns off the preprocessor, and it will be on by default. I'll also, finally, get the options working to output the archive file list and object tree list.
Doing some tests with BSTC and OpenSpin related to the program size output. In my test case the compiled binary file is 7016 bytes in size on disk (OS reported). BSTC reports the size at 7012 longs. and OpenSpin reports the size as 7436 bytes. Obviously, both are wrong.
I figured out that OpenSpin was reporting the size of the program + the size of var space which isn't in the binary file output. I've fixed OpenSpin to now output the proper binary size in bytes (so in my test case it says 7016 bytes).
BSTC seems to be reporting the size of the program minus the first 4 bytes (which is the clock config stuff), but it's bytes even though it says longs.
Roy
Built on Mac OS X 10.8.4
Test compiled 1 large project, to success
Note: you may want to change this description of the -D DEFINE option:
As the pre-processor is ON by default now.
dgately
Roy
sh-3.1$ openspin pjvm_demo.spin Propeller Spin/PASM Compiler 'OpenSpin' (c)2012-2013 Parallax Inc. DBA Parallax Semiconductor. Compiled on Aug 21 2013 Compiling... pjvm_demo.spin |-FullDuplexSingleton.spin |-pjvmInterpreterCOG.spin |-PasmA0EEPROM.spin |-pjdata.spin |-pjcon.spin |-FullDuplexSingleton.spin |-PasmA0EEPROM.spin |-pjcon.spin |-pjdata.spin |-pjcon.spin |-FullDuplexSingleton.spin |-PasmA0EEPROM.spin |-pjcon.spin |-pnative.spin |-pjdef.spin |-pjdata.spin |-pjcon.spin |-FullDuplexSingleton.spin |-PasmA0EEPROM.spin |-pjvmvp.spin |-pjdef.spin |-FullDuplexSingleton.spin |-PasmA0EEPROM.spin |-properties.spin Done. Program size is 15556 bytes sh-3.1$I think we are now at a point where I am interested in switching to SimpleIDE + OpenSpin.
Just for reference, I use PropTool, bst, homespun in that order as my code requires increased complexity. It will be much nicer to stay in one environment - thanks for your efforts Roy & Steve, etc.
Roy,
I'm getting errors compiling open-spin on Mac OS X with r53. Does seem to point to the changes between r52 & r53... Fix looks simple!
PATH_MAX seems to be only declared for WIN32 in r53 (seen in the diff file from:http://code.google.com/p/open-source-spin-compiler/source/diff?spec=svn53&r=53&format=side&path=/SpinSource/openspin.cpp )
From that point, the other var's declarations seemed to get missed, as well.
I searched for 'filesaccessed' in the diff for r53 and do see that this is a new var for this revision. Looks like it does get declared on line line 79 of openspin.cpp, but the compiler is not seeing the declaration later in the same source file.
To test: I moved the line (57) "#define PATH_MAX 256" back above line (56) "#if defined(WIN32)" and it compiles once again...
dgately
Sorry about that, I made that change because on linux is appears that PATH_MAX is defined already by the stdlib inlude, and I had assumed it would be the same on OSX. The issue is that if PATH_MAX is some value larger than 256 in the linux includes, then it's possible that the call to realpath() could overflow our buffer. I'll work out a fix for this tonight when I get home.
Thanks for all these great changes and keeping this going! Having an open source tool chain for prop development is "way cool!".
dgately
I've put up a small change that should build on OSX now. I didn't do new downloads of the exe or source for this one since it only matters to OSX people who need to build themselves anyway. So go get r54 and see if it builds properly on OSX now.
Builds on 10.8.4, without issue!
dgately
First of all, thanks for questioning the DAT only feature, because I found a bug in there that would cause it to output incorrectly depending on how many OBJ references you had in the top object. It was actually only correct if the top object had exactly one OBJ reference. If it had none or more than one, then the DAT only output was wrong. I've changed code to fix this.
I've also found that if you have a FIT at the end of your DAT section, my code was padding the size at that point to a multiple of 4 bytes. This is what I believe you are seeing in your case. I've also put in a code fix for this.
I haven't done a full build with these fixes yet. I'll do a build later tonight (Saturday night).
PUB null DAT first long -1 [COLOR="#FFA500"]word label[/COLOR] label fit 16 DATPropeller Spin/PASM Compiler 'OpenSpin' (c)2012-2013 Parallax Inc. DBA Parallax Semiconductor. Compiled on Aug 24 2013 Compiling... a.spin a.spin(5:25) : error : Undefined symbol Line: word label Offending Item: labelUsing word first works fine and in this particular case emits 6 bytes (openspin -c a.spin).Ok, I undid part of that change, check the new source. 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.
Interestingly, none of the 1462 OBEX files I tested with have a label on the FIT directive line, so they all compiled successfully. It's good to have someone like you that tries all the weird things that no one else does and catches these kinds of thing.