bst.linux loads my demo board just fine as long as I don't include any libraries.
It must be a permission problem somewhere though because it works fine as root:
maniac:/home/doug/mcu/propeller # ./bstc.linux -L /home/doug/mcu/propeller/proptool Display2.spin
Brads SpinTool Compiler v0.12 - Copyright 2008, All rights reserved
Compiled for i386 Linux at 20:19:19 on 2008/12/22
Found a USB Serial Device
Loading Object Display2
Loading Object Numbers
Loading Object TV_Terminal
Loading Object tv
Loading Object graphics
Compiled 1984 Lines of Code in 0.103 Seconds
Yes, it is a permissions problem and bstc can't open a file you are asking it to open. I actually fixed that problem yesterday as I swept through looking for other IO errors I was not handling properly. (it will now tell you the path of the file it can't open)
Try this pre-release version (read as not passed though QA for release) and see how it pans out for you. www.fnarfbargle.com/bstc.linux.zip
I'd be interested to see how the loader works for you also as it has been *significantly* improved for speed and reliability. It now loads the propeller on average 20% faster than the Parallax tool as it uses a "dense packing" technique developed by Hippy to download more bits per byte.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
I really appreciate you working on this. I now get a more meaningful message, but it still doesn't work right unless I am root. See below:
maniac:~/mcu/propeller> ./bstc.linux -L /home/doug/mcu/propeller/proptool Display2.spin
Brads Spin Tool Compiler v0.13-pre1 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 07:57:09 on 2009/02/06
Found a USB Serial Device
Loading Object Display2
Loading Object Numbers
Numbers - Unable to open file ./Numbers.spin
Compiled 23 Lines of Code in 0.004 Seconds
maniac:~/mcu/propeller> /bin/su
Password:
maniac:/home/doug/mcu/propeller # ./bstc.linux -L /home/doug/mcu/propeller/proptool Display2.spin
Brads Spin Tool Compiler v0.13-pre1 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 07:57:09 on 2009/02/06
Found a USB Serial Device
Loading Object Display2
Loading Object Numbers
Loading Object TV_Terminal
Loading Object tv
Loading Object graphics
Compiled 1984 Lines of Code in 0.089 Seconds
maniac:/home/doug/mcu/propeller #
If it says it can't open it, there must be a permissions issue stopping you from reading that file as your normal user. Did you create that file as Root?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
maniac:~/mcu/propeller> strace -o log ./bstc.linux -L /home/doug/mcu/propeller/proptool Display2.spin
[noparse][[/noparse] Process PID=18869 runs in 32 bit mode. ]
Brads Spin Tool Compiler v0.13-pre1 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 07:57:09 on 2009/02/06
Found a USB Serial Device
Loading Object Display2
Loading Object Numbers
Numbers - Unable to open file ./Numbers.spin
Compiled 23 Lines of Code in 0.053 Seconds
maniac:~/mcu/propeller>
Hrm.. do you have a file called Numbers.spin in ~/mcu/propeller ?
What does
ls -la /home/doug/mcu/propeller/Numbers.spin
say ?
I have found a bug.. in that for whatever reason I'm trying to open all spin files RW rather than RO.. but still.. you showed me the ls of /home/doug/mcu/propeller/proptool/Numbers.spin, but it appears to be trying to open /home/doug/mcu/propeller/Numbers.spin
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Using the "|<" operator in a repeat statement fails with a "unrecognized operator" or some such error. The Propeller tool is perfectly happy with this. (I'm doing this as I'm too lazy to write 1<<MyVar) The funny thing is that BSTC was perfectly happy with my use of the "|<" operator in the CON block of my code.
Thanks,
Lawson
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Lunch cures all problems! have you had lunch?
I removed it, now it is working. But why wouldn't it be able to open Numbers.spin since it was owned by me anyway?
The problem lies in my file handling code. It's trying to open the file read/write instead of read-only and you did not have write permission for that file. I'll get that fixed though..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Using the "|<" operator in a repeat statement fails with a "unrecognized operator" or some such error. The Propeller tool is perfectly happy with this. (I'm doing this as I'm too lazy to write 1<<MyVar) The funny thing is that BSTC was perfectly happy with my use of the "|<" operator in the CON block of my code.
Thanks,
Lawson
Thanks for the report. It's fixed in the upcoming release.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
case var
"a":
'do stuff
"b":
'do other stuff
"c":
'have a party
I've used this code as a quick and dirty way to branch code when a serial byte is received and stuffed in "var." Works exactly as intended in the PropTool. When compiled with BSTC the "a" condition is accessible, but runs even when a "b" or "c" is sent. The code for the "b" and "c" conditions can't be run. This can be worked around by replacing "a", "b", and "c" with the appropriate ASCII codes.
An additional clue'
repeat while serial.rxcheck <> "q"
works exactly the same with both the proptool and bstc.
False alarm, my partner in crime didn't check his assumptions.
Lawson
P.S. I'm sending these bug reports second hand from the programmer I'm working with. he's a crack linux programmer and could probably fix a lot of this stuff faster than he can tell me what's wrong. Where's the source for BSTC? I'm blind and can't seem to find it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Lunch cures all problems! have you had lunch?
False alarm, my partner in crime didn't check his assumptions.
Lawson
P.S. I'm sending these bug reports second hand from the programmer I'm working with. he's a crack linux programmer and could probably fix a lot of this stuff faster than he can tell me what's wrong. Where's the source for BSTC? I'm blind and can't seem to find it.
I appreciate the bug reports none the less. The source is currently on my laptop.
I have a new release in testing currently.. but I've been saying that for a week now.. I apologise.. please bear with me, I keep changing stuff and I don't want to get it out before I'm convinced it's as good as I can make it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
I have a new release in testing currently.. but I've been saying that for a week now.. I apologise.. please bear with me, I keep changing stuff and I don't want to get it out before I'm convinced it's as good as I can make it.
Something else to check : on 0.12, if I use too much memory, I get an exception :
ERROR : Numbers - Binary too large for RAM by 31 Longs
Compiled 5020 Lines of Code in 1.113 Seconds
An unhandled exception occurred at $00000000 :
EAccessViolation : Access violation
$00000000
$08048355
Currently. I can recover enough space to build by using -Ogc, but if I use -Ogcr the resulting binary falls over in nasty ways.
Sorry about the poor detail in this report : if I get a chance I'll try to find out a bit more about what's going on. It's likely that there isn't really a problem with the optimisation but that I'm short of stack and it fails differently according to how the code is rearranged.
Something else to check : on 0.12, if I use too much memory, I get an exception :
ERROR : Numbers - Binary too large for RAM by 31 Longs
Compiled 5020 Lines of Code in 1.113 Seconds
An unhandled exception occurred at $00000000 :
EAccessViolation : Access violation
$00000000
$08048355
Currently. I can recover enough space to build by using -Ogc, but if I use -Ogcr the resulting binary falls over in nasty ways.
Sorry about the poor detail in this report : if I get a chance I'll try to find out a bit more about what's going on. It's likely that there isn't really a problem with the optimisation but that I'm short of stack and it fails differently according to how the code is rearranged.
Can you send me the source that explodes? brad_at_fnarfbargle.com
I *thought* I had fixed those a couple of releases ago, but that stack trace says that I'm dereferencing a null pointer. I'd love to get it fixed..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Lots of bug fixes (a BIG thanks to all reporters, especially those sending me their un-distributable code in private to allow me to get the nasty bugs)
This one has a few new bits.
The (-c) command line option now properly generates a .dat file for use when including PASM drivers in for "C" Compilers. I promised this feature to Richard last year, and I actually implemented half of it but I forgot to implement the bit that actually writes the file. I apologise for my tardiness!
I've started to play a little catchup to mpark's homespun by adding information messages and warnings to the compiler output. There are 3 levels of output messages now :
default is errors only
-w1 gives you warnings also (res after dat, jmp/djnz without # and so on)
-w2 gives you information also (unused global variables, unused SPIN methods and so on).
The prop loader has been improved (and sped up) significantly, see the changelog for bstl for details.
I've modified the unused method removal code. Previously it would just point unused methods at the last instruction in the previous method (which is always a $32-Return), but agodwin has been finding that the binaries it generated have been dying in very bizzare ways, so as a temporary experiment I've made all unused methods simply generate a single "Return" instruction. We'll see if this helps. I can't get it to break any of my binaries, but then that's generally software development for you! If anyone finds a simple case where the unused method removal makes the binary misbehave I'd *love* to get my hands on it, it just refuses to break for me and its driving me nuts!
If you use the bst suite exclusively rather than the Parallax compiler or Homespun you might find some of your code no longer compiles properly. I had three bugs in the compiler that made it far more relaxed than the Parallax compiler that agodwin spotted and I've fixed them, so you may find stuff that was not valid spin that compiled previously no longer does.
The details are all in the changelog for those interested.
I have tried to address every bug reported, but if I've missed one please let me know.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Ok, I'm _really_ sorry guys, but the (-c) option for dropping .dat files is broken. It starts too early in the binary. I'll try again and get it right.. [noparse]:([/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
I have tried the -r flag again and do get a working binary. However, I haven't retried with the failing sources I had before (which used more memory) so may not be quite the same situation.
Relaxed checks on using float numbers in spin expressions. Converted the error into a warning.
Fix for errors on Spin methods with () and no parameters.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Added #define and friends. As this is a Non-Parallax compatible construct, you must enable this with the "x" optimisation option (-Ox) or (-Oa). In future, all Non-Parallax constructs will be enabled by this option.
We have :
#define / #undef / #ifdef / #ifndef / #elseifdef / #elseifndef / #else / #endif
Additionally we also have :
#warn / #info / #error
Now, in Homespun the defines are local to a file. In bst[noparse][[/noparse]c] they are global, so if you define something in the top object it is passed down to all children. If you define something in child one it is passed to child two and so on.. this allows constructs like this in sub-objects :
#ifdef TriBlade
' Some code
#info Board definition is TriBlade
#elseifdef DemoBoard
' Some more code
#info Board definition is Parallax Demo Board
#else
#Error No Board defined!
#endif
or :
#ifdef Gronk
#warn Gronk already defined
#else
#define Gronk
#endif
As with Homespun, all defines must be in the first column.
It has been very lightly tested and compiles zicog_demo close enough to identically to homespun (there is a binary difference due to the different way we sort our SPIN STRING() data).
The error handling might be a bit light-on.. but I've tested most of the obvious permutations and not managed to blow it up much. As always, feedback is warmly welcomed.
There are 5 or 6 other bug fixes in this upload also, nothing major but a couple of brown paper bags.. I'll try to get this properly validated in the next couple of days and issued as an actual release.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
Have You added posiblity to generate large BINARY files for LMM, XMM Memory models to BSTC.
For Posiblity to run LMM code from Extended memory type Triblade (Blade1, Blade2).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
On my windows I have Compile error with BSTC v15.3
Look on pictures
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Have You added posiblity to generate large BINARY files for LMM, XMM Memory models to BSTC.
For Posiblity to run LMM code from Extended memory type Triblade (Blade1, Blade2).
No, not yet. I'm still considering how best to do it really. The problem is as soon as your DAT block exceeds a little under 64k the pointers and calculations in the SPIN blocks explode into a little fireball. I'm considering how to allow the generation of a large DAT block while not placing any specific hacks in the SPIN portion of the compiler.
Given all the LMM/XMM stuff really is PASM only, I'd have thought you would have been better/quicker to modify Cliffs java based assembler as you don't need to link or process objects in any way.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
Can't You not give out another BSTC-P (BPTC) for pure PASM assembly with no limits on PASM/BIN length code
And have one option in BST with compiler will be used.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Thanks for the #define etc functions. I shall give it a try over the next few days.
Until I started using the #define statements in homespun, I had just not thought how good they were. Now I use them for all sorts of tests (debug code) so I can have lots of options such as CPM 2 or CPM 3 compiles with only a #define change.
Curently I am using PropTool to edit/save and homespun to compile, then PropTool to load the binary. BST should simplify this. I am now way past going back to PropTool for anything complex. Thanks to you and michael
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Guys, please note this is bst(C) not bst. While I've got an updated version of bst with the #define..etc I'm not quite ready to publish it yet. Only the command line compiler has the extensions enabled!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
brad@bkmac:~/zicog_v0_9$ bstc -Ox zicog_demo.spin -p0 -f
Found a USB Serial Device
Brads Spin Tool Compiler v0.15-pre5 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 14:28:53 on 2009/05/07
Loading Object zicog_demo
Loading Object zicog
Loading Object sdspiqasm
Loading Object PC_Keyboard
Loading Object PC_Text
Compiled 1923 Lines of Code in 0.146 Seconds
We found a Propeller Version 1
Propeller Load took 3.708 Seconds
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
BradC:
I am a little lost. I am on windoze vista. I am presuming from your statement above, I can only compile ZiCog/TriBlade using the command line version and with the defines as part of the command line. It this correct?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Comments
It must be a permission problem somewhere though because it works fine as root:
maniac:/home/doug/mcu/propeller # ./bstc.linux -L /home/doug/mcu/propeller/proptool Display2.spin
Brads SpinTool Compiler v0.12 - Copyright 2008, All rights reserved
Compiled for i386 Linux at 20:19:19 on 2008/12/22
Found a USB Serial Device
Loading Object Display2
Loading Object Numbers
Loading Object TV_Terminal
Loading Object tv
Loading Object graphics
Compiled 1984 Lines of Code in 0.103 Seconds
Try this pre-release version (read as not passed though QA for release) and see how it pans out for you.
www.fnarfbargle.com/bstc.linux.zip
I'd be interested to see how the loader works for you also as it has been *significantly* improved for speed and reliability. It now loads the propeller on average 20% faster than the Parallax tool as it uses a "dense packing" technique developed by Hippy to download more bits per byte.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
I really appreciate you working on this. I now get a more meaningful message, but it still doesn't work right unless I am root. See below:
maniac:~/mcu/propeller> ./bstc.linux -L /home/doug/mcu/propeller/proptool Display2.spin
Brads Spin Tool Compiler v0.13-pre1 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 07:57:09 on 2009/02/06
Found a USB Serial Device
Loading Object Display2
Loading Object Numbers
Numbers - Unable to open file ./Numbers.spin
Compiled 23 Lines of Code in 0.004 Seconds
maniac:~/mcu/propeller> /bin/su
Password:
maniac:/home/doug/mcu/propeller # ./bstc.linux -L /home/doug/mcu/propeller/proptool Display2.spin
Brads Spin Tool Compiler v0.13-pre1 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 07:57:09 on 2009/02/06
Found a USB Serial Device
Loading Object Display2
Loading Object Numbers
Loading Object TV_Terminal
Loading Object tv
Loading Object graphics
Compiled 1984 Lines of Code in 0.089 Seconds
maniac:/home/doug/mcu/propeller #
ls -la ./Numbers.spin
If it says it can't open it, there must be a permissions issue stopping you from reading that file as your normal user. Did you create that file as Root?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
-rw-r--r-- 1 doug users 90162 2008-01-29 13:31 proptool/Numbers.spin
maniac:/home/doug/mcu/propeller #
strace -o log ./bstc.linux -L /home/doug/mcu/propeller/proptool Display2.spin
and mail or PM me the log file please?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
[noparse][[/noparse] Process PID=18869 runs in 32 bit mode. ]
Brads Spin Tool Compiler v0.13-pre1 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 07:57:09 on 2009/02/06
Found a USB Serial Device
Loading Object Display2
Loading Object Numbers
Numbers - Unable to open file ./Numbers.spin
Compiled 23 Lines of Code in 0.053 Seconds
maniac:~/mcu/propeller>
What does
ls -la /home/doug/mcu/propeller/Numbers.spin
say ?
I have found a bug.. in that for whatever reason I'm trying to open all spin files RW rather than RO.. but still.. you showed me the ls of /home/doug/mcu/propeller/proptool/Numbers.spin, but it appears to be trying to open /home/doug/mcu/propeller/Numbers.spin
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
-r
1 doug users 85956 2007-02-25 22:16 Numbers.spin
I removed it, now it is working. But why wouldn't it be able to open Numbers.spin since it was owned by me anyway?
Thanks for you help,
Doug
Post Edited (hinv) : 2/6/2009 10:42:09 PM GMT
Using the "|<" operator in a repeat statement fails with a "unrecognized operator" or some such error. The Propeller tool is perfectly happy with this. (I'm doing this as I'm too lazy to write 1<<MyVar) The funny thing is that BSTC was perfectly happy with my use of the "|<" operator in the CON block of my code.
Thanks,
Lawson
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Lunch cures all problems! have you had lunch?
The problem lies in my file handling code. It's trying to open the file read/write instead of read-only and you did not have write permission for that file. I'll get that fixed though..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Thanks for the report. It's fixed in the upcoming release.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
case var "a": 'do stuff "b": 'do other stuff "c": 'have a partyI've used this code as a quick and dirty way to branch code when a serial byte is received and stuffed in "var." Works exactly as intended in the PropTool. When compiled with BSTC the "a" condition is accessible, but runs even when a "b" or "c" is sent. The code for the "b" and "c" conditions can't be run. This can be worked around by replacing "a", "b", and "c" with the appropriate ASCII codes.
An additional clue'
works exactly the same with both the proptool and bstc.
False alarm, my partner in crime didn't check his assumptions.
Lawson
P.S. I'm sending these bug reports second hand from the programmer I'm working with. he's a crack linux programmer and could probably fix a lot of this stuff faster than he can tell me what's wrong. Where's the source for BSTC? I'm blind and can't seem to find it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Lunch cures all problems! have you had lunch?
Post Edited (Lawson) : 2/11/2009 11:12:31 PM GMT
I appreciate the bug reports none the less. The source is currently on my laptop.
I have a new release in testing currently.. but I've been saying that for a week now.. I apologise.. please bear with me, I keep changing stuff and I don't want to get it out before I'm convinced it's as good as I can make it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Something else to check : on 0.12, if I use too much memory, I get an exception :
ERROR : Numbers - Binary too large for RAM by 31 Longs
Compiled 5020 Lines of Code in 1.113 Seconds
An unhandled exception occurred at $00000000 :
EAccessViolation : Access violation
$00000000
$08048355
Currently. I can recover enough space to build by using -Ogc, but if I use -Ogcr the resulting binary falls over in nasty ways.
Sorry about the poor detail in this report : if I get a chance I'll try to find out a bit more about what's going on. It's likely that there isn't really a problem with the optimisation but that I'm short of stack and it fails differently according to how the code is rearranged.
Can you send me the source that explodes? brad_at_fnarfbargle.com
I *thought* I had fixed those a couple of releases ago, but that stack trace says that I'm dereferencing a null pointer. I'd love to get it fixed..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Changelog in top post.
Lots of bug fixes (a BIG thanks to all reporters, especially those sending me their un-distributable code in private to allow me to get the nasty bugs)
This one has a few new bits.
The (-c) command line option now properly generates a .dat file for use when including PASM drivers in for "C" Compilers. I promised this feature to Richard last year, and I actually implemented half of it but I forgot to implement the bit that actually writes the file. I apologise for my tardiness!
I've started to play a little catchup to mpark's homespun by adding information messages and warnings to the compiler output. There are 3 levels of output messages now :
default is errors only
-w1 gives you warnings also (res after dat, jmp/djnz without # and so on)
-w2 gives you information also (unused global variables, unused SPIN methods and so on).
The prop loader has been improved (and sped up) significantly, see the changelog for bstl for details.
I've modified the unused method removal code. Previously it would just point unused methods at the last instruction in the previous method (which is always a $32-Return), but agodwin has been finding that the binaries it generated have been dying in very bizzare ways, so as a temporary experiment I've made all unused methods simply generate a single "Return" instruction. We'll see if this helps. I can't get it to break any of my binaries, but then that's generally software development for you! If anyone finds a simple case where the unused method removal makes the binary misbehave I'd *love* to get my hands on it, it just refuses to break for me and its driving me nuts!
If you use the bst suite exclusively rather than the Parallax compiler or Homespun you might find some of your code no longer compiles properly. I had three bugs in the compiler that made it far more relaxed than the Parallax compiler that agodwin spotted and I've fixed them, so you may find stuff that was not valid spin that compiled previously no longer does.
The details are all in the changelog for those interested.
I have tried to address every bug reported, but if I've missed one please let me know.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
I have tried the -r flag again and do get a working binary. However, I haven't retried with the failing sources I had before (which used more memory) so may not be quite the same situation.
-adrian
If you are the one person that expected the (-c) option to work properly, this fixes it.
No other changes aside from the version number. None..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Relaxed checks on using float numbers in spin expressions. Converted the error into a warning.
Fix for errors on Spin methods with () and no parameters.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Added #define and friends. As this is a Non-Parallax compatible construct, you must enable this with the "x" optimisation option (-Ox) or (-Oa). In future, all Non-Parallax constructs will be enabled by this option.
We have :
#define / #undef / #ifdef / #ifndef / #elseifdef / #elseifndef / #else / #endif
Additionally we also have :
#warn / #info / #error
Now, in Homespun the defines are local to a file. In bst[noparse][[/noparse]c] they are global, so if you define something in the top object it is passed down to all children. If you define something in child one it is passed to child two and so on.. this allows constructs like this in sub-objects :
#ifdef TriBlade
' Some code
#info Board definition is TriBlade
#elseifdef DemoBoard
' Some more code
#info Board definition is Parallax Demo Board
#else
#Error No Board defined!
#endif
or :
#ifdef Gronk
#warn Gronk already defined
#else
#define Gronk
#endif
As with Homespun, all defines must be in the first column.
It has been very lightly tested and compiles zicog_demo close enough to identically to homespun (there is a binary difference due to the different way we sort our SPIN STRING() data).
The error handling might be a bit light-on.. but I've tested most of the obvious permutations and not managed to blow it up much. As always, feedback is warmly welcomed.
There are 5 or 6 other bug fixes in this upload also, nothing major but a couple of brown paper bags.. I'll try to get this properly validated in the next couple of days and issued as an actual release.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
Have You added posiblity to generate large BINARY files for LMM, XMM Memory models to BSTC.
For Posiblity to run LMM code from Extended memory type Triblade (Blade1, Blade2).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
On my windows I have Compile error with BSTC v15.3
Look on pictures
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
No, not yet. I'm still considering how best to do it really. The problem is as soon as your DAT block exceeds a little under 64k the pointers and calculations in the SPIN blocks explode into a little fireball. I'm considering how to allow the generation of a large DAT block while not placing any specific hacks in the SPIN portion of the compiler.
Given all the LMM/XMM stuff really is PASM only, I'd have thought you would have been better/quicker to modify Cliffs java based assembler as you don't need to link or process objects in any way.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
Can't You not give out another BSTC-P (BPTC) for pure PASM assembly with no limits on PASM/BIN length code
And have one option in BST with compiler will be used.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Until I started using the #define statements in homespun, I had just not thought how good they were. Now I use them for all sorts of tests (debug code) so I can have lots of options such as CPM 2 or CPM 3 compiles with only a #define change.
Curently I am using PropTool to edit/save and homespun to compile, then PropTool to load the binary. BST should simplify this. I am now way past going back to PropTool for anything complex. Thanks to you and michael
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
Added -D option to allow specifying defines on the command line...
bstc -Ox -D gronk -D tribladeprop test.spin
www.fnarfbargle.com/bst/snapshots
brad@bkmac:~/zicog_v0_9$ bstc -Ox zicog_demo.spin -p0 -f
Found a USB Serial Device
Brads Spin Tool Compiler v0.15-pre5 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 14:28:53 on 2009/05/07
Loading Object zicog_demo
Loading Object zicog
Loading Object sdspiqasm
Loading Object PC_Keyboard
Loading Object PC_Text
Compiled 1923 Lines of Code in 0.146 Seconds
We found a Propeller Version 1
Propeller Load took 3.708 Seconds
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
Post Edited (BradC) : 5/7/2009 6:37:12 AM GMT
I am a little lost. I am on windoze vista. I am presuming from your statement above, I can only compile ZiCog/TriBlade using the command line version and with the defines as part of the command line. It this correct?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm