How many people (if anyone actually uses this aside from me) use GNU makefiles?
I've had a request to change the behaviour of the compiler when specifying an output prefix using -o.
At the moment, -o is the prefix, so if you used..
bstc -o fred -b -e -ls test.spin
It would compile test.spin and create fred.binary, fred.eeprom & fred.list
I'm thinking that I want to retain this functionality, but maybe if used in a makefile you would only use one command at a time. Either -b / -e / -ls
.. so if you used
bstc -o fred.binary -b test.spin
You would get fred.binary.
If, however you used
bstc -o fred.binary -b -e -ls test.spin
You would get fred.binary, fred.binary.eeprom, fred.binary.list. - Complex and ugly, but would it satisfy the requirement I wonder?
Along those lines, bstc -o fred.eeprom -b -e -ls test.spin would drop fred.eeprom.binary, fred.eeprom, fred.eeprom.list.
Can anyone think of a better way to handle this?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
I use GNU Makfiles exclusively. What's the reasoning for the request?
--jc
BradC said...
Feedback request.
How many people (if anyone actually uses this aside from me) use GNU makefiles?
I've had a request to change the behaviour of the compiler when specifying an output prefix using -o.
At the moment, -o is the prefix, so if you used..
bstc -o fred -b -e -ls test.spin
It would compile test.spin and create fred.binary, fred.eeprom & fred.list
I'm thinking that I want to retain this functionality, but maybe if used in a makefile you would only use one command at a time. Either -b / -e / -ls
.. so if you used
bstc -o fred.binary -b test.spin
You would get fred.binary.
If, however you used
bstc -o fred.binary -b -e -ls test.spin
You would get fred.binary, fred.binary.eeprom, fred.binary.list. - Complex and ugly, but would it satisfy the requirement I wonder?
Along those lines, bstc -o fred.eeprom -b -e -ls test.spin would drop fred.eeprom.binary, fred.eeprom, fred.eeprom.list.
BradC said...
How many people (if anyone actually uses this aside from me) use GNU makefiles?
+1
Having said that, I'm happy with the default behaviour (i.e. SPIN file basename) so haven't used -o yet. And yes, it sounds like a strange request. Wouldn't it be easier to do the renaming as part of the build process (regardless of whether Makefiles are used or not)?
BradC said...
How many people (if anyone actually uses this aside from me) use GNU makefiles?
+1
Having said that, I'm happy with the default behaviour (i.e. SPIN file basename) so haven't used -o yet. And yes, it sounds like a strange request. Wouldn't it be easier to do the renaming as part of the build process (regardless of whether Makefiles are used or not)?
I would have thought so. What I ended up implementing was a half-arsed hack that kinda did the job but left the rest of us unaffected.
If you specify -o fred.binay in conjunction with -b it will drop fred.binary. If you were to use -l or -e you would get fred.binary.eeprom and fred.binary.list, which is pretty grungy, but it was a quick hack.
The only time I use -o is in my regression test suite. It's convenient to have the output file with a consistent name in a consistent location to do binary diffs against.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
bstc happily allows to use RES address as SPIN variable. Propeller tool would not allow this, and that is correct behavior - HUB memory address of RES can belong to anything (object's byte code in bstc's case, not sure about propeller tool)
bstc happily allows to use RES address as SPIN variable. Propeller tool would not allow this, and that is correct behavior - HUB memory address of RES can belong to anything (object's byte code in bstc's case, not sure about propeller tool)
I'm a bit torn on what to do with this one. The Propeller tool is inconsistent here.
AA long 0
BB res 1
CC long 1
AA & CC are valid symbols for spin. BB is not.
AA long 0
BB
res 1
CC long 1
Now, AA, BB & CC are valid symbols for spin.
Doing what the Prop tool does and only making the symbol invalid if it is immediately followed by a res is possible, but requires special casing and feels quite inconsistent to me.
I'm not ruling it out, I just wonder if it does not need a bit more thought. Comments?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
I would consider this as bug in Propeller Tool. RES does not occupy main RAM - so it should not be accesible from SPIN. Moreover - the manual clearly recommends placing all RES at the end of object code. Allowing access to RES in such case is obviously a bug - since it leads to memory corruption
It not necessary any BUG.
If I will have defined 2 or more names to same Variable it are handy.
In my opinion Both versions that BradC posted need compile correctly -
AS Extra name to variable CC - That means both BB and CC will have same physical address.
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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.
1. You do not need a RES to make 2 names refer same memory address
2. I do not think this is correct - BB and CC would be same for SPIN only - but not for COG running assembly
@Brad: Is there any chance for a quiet option to hide the noise behind? It's sort of OK for a couple of files but when the list grows larger (Makefile usage) then it's just not too useful. Thanks.
kuroneko said...
@Brad: Is there any chance for a quiet option to hide the noise behind? It's sort of OK for a couple of files but when the list grows larger (Makefile usage) then it's just not too useful. Thanks.[noparse][[/noparse]/quote
Sure. I'm doing fixes to the tools this weekend, I'll try and get something knocked out.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Does anyone use -l without -s (generate list but don't insert the original source) ?
I added an option for jazzed to make it easier to parse the list file output for his debugger. In order to do this I changed the way -l works.
Previously, you used -l to generate a list file, then -s if you wanted the source added.
Now you use -l to generate a list file. Adding (s) to that adds the source, and adding (m) makes it a bit easier for a machine to read, so the whole box and dice would be -lms.
The issue here is as the input file name is specified without a marker, using -l immediately prior to the filename makes it look like the file name is the argument to the -l option.
I have 2 possible solutions to this. One is to add another option (a) which means alone. So -la would be "just give me the list file" while (s) and (m) behave as previously. -l alone would be an invalid parameter. The other is to make the (s) mandatory so the source is *always* included in the list file output.
I'm leaning toward the (a) myself, as it provides the flexibility we already have and really only changes the way the options are specified.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Brad, what is the reason for not evaluating constant expressions at compile time? In the code below two last statements are identical - and that is known at compile time, but emit different code blocks, one being both bigger and slower. This is an artifical example, of course, but I am sure real life programs do have similar patterns
con
base1 = 128
base2 = 256
elemnet1 = 10
elemnet2 = 11
var
long a[noparse][[/noparse]512]
pub x
a[noparse][[/noparse]base1 + elemnet1] := 2
a[noparse][[/noparse]base1 + elemnet2] := 3
a[noparse][[/noparse]base2 + elemnet2] := 4
a[noparse][[/noparse]267] := 4
Spin Block x with 0 Parameters and 0 Extra Stack Longs. Method 1
pub x
Local Parameter DBASE:0000 - Result
|===========================================================================|
test.spin::11 a[noparse][[/noparse]base1 + elemnet1] := 2
Addr : 0018: 37 00 : Constant Mask Y=0 00000002 2
Addr : 001A: 37 06 : Constant Mask Y=6 00000080 128
Addr : 001C: 38 0A : Constant 1 Bytes - 0A - $0000000A 10
Addr : 001E: EC : Math Op +
Addr : 001F: D9 00 : Memory Op Long VBASE + POP Index WRITE Address = 0000
test.spin::12 a[noparse][[/noparse]base1 + elemnet2] := 3
Addr : 0021: 37 21 : Constant Mask Y=33 Decrement 00000003 3
Addr : 0023: 37 06 : Constant Mask Y=6 00000080 128
Addr : 0025: 38 0B : Constant 1 Bytes - 0B - $0000000B 11
Addr : 0027: EC : Math Op +
Addr : 0028: D9 00 : Memory Op Long VBASE + POP Index WRITE Address = 0000
test.spin::13 a[noparse][[/noparse]base2 + elemnet2] := 4
Addr : 002A: 37 01 : Constant Mask Y=1 00000004 4
Addr : 002C: 37 07 : Constant Mask Y=7 00000100 256
Addr : 002E: 38 0B : Constant 1 Bytes - 0B - $0000000B 11
Addr : 0030: EC : Math Op +
Addr : 0031: D9 00 : Memory Op Long VBASE + POP Index WRITE Address = 0000
test.spin::14 a[noparse][[/noparse]267] := 4
Addr : 0033: 37 01 : Constant Mask Y=1 00000004 4
Addr : 0035: 39 01 0B : Constant 2 Bytes - 01 0B - $0000010B 267
Addr : 0038: D9 00 : Memory Op Long VBASE + POP Index WRITE Address = 0000
test.spin::15 return 0
Addr : 003A: 32 : Return
Andrey Demenev said...
Brad, what is the reason for not evaluating constant expressions at compile time? In the code below two last statements are identical - and that is known at compile time, but emit different code blocks, one being both bigger and slower. This is an artifical example, of course, but I am sure real life programs do have similar patterns
Are you using -Oc ? It should fold all easy constant expressions at compile time.
Andrey Demenev said...
Brad, what is the reason for not evaluating constant expressions at compile time? In the code below two last statements are identical - and that is known at compile time, but emit different code blocks, one being both bigger and slower. This is an artifical example, of course, but I am sure real life programs do have similar patterns
Sorry, in answer to your question bst[noparse][[/noparse]c] does not do it by default as the Parallax compiler does not do it. If you don't use any of the -O features, the output is bit for bit identical with the Propeller Tool (which has always been my intent). If you use some of the -O features (I use -Oa all the time personally), then all bets are off, but you usually save a couple of longs at least.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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.
This one has the unused method & object elimination done right. (Well, I've tested it and can't break it here anyway - the theory is sound)
The last mess up was a result of a quick hack, and required a black Sambuca and 2 hours of band rehearsal to get it straight in my head.
Anyway. the result is it works. Using -Oa reduces the size of the standard Propeller Demo by about 78 longs with no impact in functionality (well, the constant folding might have made it a teensy bit quicker).
My generic all singing and dancing demo I use one one of my proto boards slims down by nearly 1000 longs (It has a lot of stuff that is optionally enabled).
Previous versions removed method bytecode, but left the objects and method tables present. That still consumed a long per original method in the method table. Now, if there is no spin method in the object referenced, the whole object disappears completely.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
andrey@debian:/tmp/testbug$ bstc o1.spin
Found a USB Serial Device
Brads Spin Tool Compiler v0.15.3 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 08:17:46 on 2009/07/20
Loading Object o1
Loading Object o2
Loading Object o3
o3 - Object Position is negative! - This binary will not work - Report this please!
Compiled 10 Lines of Code in 0.006 Seconds
andrey@debian:/tmp/testbug$
Actually, I created this test case after getting in trouble with a project when adding a new object to it. I cannot post the code here. The object tree looked like this:
After adding another object (respparser) under sim300, bstc enters infinite loop :
andrey@debian:~/Projects/Forpost/Firmware$ bstc -b -l -Oa Forpost.spin
Found a USB Serial Device
Brads Spin Tool Compiler v0.15.3 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 08:17:46 on 2009/07/20
Loading Object Forpost
Loading Object sim300
Loading Object serial
Loading Object FullDuplexSerial
Loading Object respparser
It hangs forever after saying "Loading Object respparser", top shows almost 100% for bstc process
with all optimizations except "r" it compiles successfully:
andrey@debian:~/Projects/Forpost/Firmware$ bstc -b -l -Obcgux Forpost.spin
Found a USB Serial Device
Brads Spin Tool Compiler v0.15.3 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 08:17:46 on 2009/07/20
Loading Object Forpost
Loading Object sim300
Loading Object serial
Loading Object FullDuplexSerial
Loading Object respparser
Program size is 1840 longs
Compiled 447 Lines of Code in 0.12 Seconds
andrey@debian:~/Projects/Forpost/Firmware$
Comments
How many people (if anyone actually uses this aside from me) use GNU makefiles?
I've had a request to change the behaviour of the compiler when specifying an output prefix using -o.
At the moment, -o is the prefix, so if you used..
bstc -o fred -b -e -ls test.spin
It would compile test.spin and create fred.binary, fred.eeprom & fred.list
I'm thinking that I want to retain this functionality, but maybe if used in a makefile you would only use one command at a time. Either -b / -e / -ls
.. so if you used
bstc -o fred.binary -b test.spin
You would get fred.binary.
If, however you used
bstc -o fred.binary -b -e -ls test.spin
You would get fred.binary, fred.binary.eeprom, fred.binary.list. - Complex and ugly, but would it satisfy the requirement I wonder?
Along those lines, bstc -o fred.eeprom -b -e -ls test.spin would drop fred.eeprom.binary, fred.eeprom, fred.eeprom.list.
Can anyone think of a better way to handle this?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
--jc
1. How the spin language is encoded in the memory? If I understood the documentation, it is the interpret.
2. Is there any documentation of Propeller serial startup communication at pins P30 and P31?
propeller.wikispaces.com/Spin+Byte+Code
propeller.wikispaces.com/Download+Protocol
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Having said that, I'm happy with the default behaviour (i.e. SPIN file basename) so haven't used -o yet. And yes, it sounds like a strange request. Wouldn't it be easier to do the renaming as part of the build process (regardless of whether Makefiles are used or not)?
I would have thought so. What I ended up implementing was a half-arsed hack that kinda did the job but left the rest of us unaffected.
If you specify -o fred.binay in conjunction with -b it will drop fred.binary. If you were to use -l or -e you would get fred.binary.eeprom and fred.binary.list, which is pretty grungy, but it was a quick hack.
The only time I use -o is in my regression test suite. It's convenient to have the output file with a consistent name in a consistent location to do binary diffs against.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Bug in 0.15.3
bstc happily allows to use RES address as SPIN variable. Propeller tool would not allow this, and that is correct behavior - HUB memory address of RES can belong to anything (object's byte code in bstc's case, not sure about propeller tool)
I'm a bit torn on what to do with this one. The Propeller tool is inconsistent here.
AA & CC are valid symbols for spin. BB is not.
AA long 0 BB res 1 CC long 1Now, AA, BB & CC are valid symbols for spin.
Doing what the Prop tool does and only making the symbol invalid if it is immediately followed by a res is possible, but requires special casing and feels quite inconsistent to me.
I'm not ruling it out, I just wonder if it does not need a bit more thought. Comments?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
It not necessary any BUG.
If I will have defined 2 or more names to same Variable it are handy.
In my opinion Both versions that BradC posted need compile correctly -
AS Extra name to variable CC - That means both BB and CC will have same physical address.
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
2. I do not think this is correct - BB and CC would be same for SPIN only - but not for COG running assembly
Right. It's inconsistent and possibly confusing. It *is* legal however.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
I added an option for jazzed to make it easier to parse the list file output for his debugger. In order to do this I changed the way -l works.
Previously, you used -l to generate a list file, then -s if you wanted the source added.
Now you use -l to generate a list file. Adding (s) to that adds the source, and adding (m) makes it a bit easier for a machine to read, so the whole box and dice would be -lms.
The issue here is as the input file name is specified without a marker, using -l immediately prior to the filename makes it look like the file name is the argument to the -l option.
I have 2 possible solutions to this. One is to add another option (a) which means alone. So -la would be "just give me the list file" while (s) and (m) behave as previously. -l alone would be an invalid parameter. The other is to make the (s) mandatory so the source is *always* included in the list file output.
I'm leaning toward the (a) myself, as it provides the flexibility we already have and really only changes the way the options are specified.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
If you use -l, you now need either an (a)/(s)/(m) after it or it will complain.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
con base1 = 128 base2 = 256 elemnet1 = 10 elemnet2 = 11 var long a[noparse][[/noparse]512] pub x a[noparse][[/noparse]base1 + elemnet1] := 2 a[noparse][[/noparse]base1 + elemnet2] := 3 a[noparse][[/noparse]base2 + elemnet2] := 4 a[noparse][[/noparse]267] := 4Are you using -Oc ? It should fold all easy constant expressions at compile time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Sorry, in answer to your question bst[noparse][[/noparse]c] does not do it by default as the Parallax compiler does not do it. If you don't use any of the -O features, the output is bit for bit identical with the Propeller Tool (which has always been my intent). If you use some of the -O features (I use -Oa all the time personally), then all bets are off, but you usually save a couple of longs at least.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
You have not changed Version number in it.
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
That's ok, I didn't fix the bug either [noparse];)[/noparse]
Well, yes I did, I just broke it worse than it was.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
This one has the unused method & object elimination done right. (Well, I've tested it and can't break it here anyway - the theory is sound)
The last mess up was a result of a quick hack, and required a black Sambuca and 2 hours of band rehearsal to get it straight in my head.
Anyway. the result is it works. Using -Oa reduces the size of the standard Propeller Demo by about 78 longs with no impact in functionality (well, the constant folding might have made it a teensy bit quicker).
My generic all singing and dancing demo I use one one of my proto boards slims down by nearly 1000 longs (It has a lot of stuff that is optionally enabled).
Previous versions removed method bytecode, but left the objects and method tables present. That still consumed a long per original method in the method table. Now, if there is no spin method in the object referenced, the whole object disappears completely.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
o1.spin:
obj o2 : "o2" PUB run returno2.spin:
obj o3 : "o3" PUB run returno3.spin:
PUB run returnActually, I created this test case after getting in trouble with a project when adding a new object to it. I cannot post the code here. The object tree looked like this:
Forpost | +---sim300 | +--serial | +--FullDuplexSerialAfter adding another object (respparser) under sim300, bstc enters infinite loop :
It hangs forever after saying "Loading Object respparser", top shows almost 100% for bstc process
with all optimizations except "r" it compiles successfully:
Cheers for that. I'll look into it.
Given "Forpost" compiles without errors with the latest release, does it actually run correctly?
<edit>
Hrm.. it's not expecting that the top object will be a duplicate of a sub object. I'm going to have to think about this somewhat.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Post Edited (BradC) : 5/3/2010 2:57:04 PM GMT