Ale said...
I know the eq. is not correct (it should be byte for HUB RAM and long for COG RAM) and that @@@ will be greater than @. It just showed up testing.
Are you using 0.18.4? I'm trying to figure out why it's hanging for a while and I'm stumped.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
here is the code that hangs bst 0.18.4 on Mac OS X and bstc 0.15- It is basically the same error as before (@label - @@@label).
Whoooooooooeeeeeeeee what a bug. This one only occurs if you are using '$' in your assembler AND you use @@@ somewhere in the same program. It's caused by a bug in the way '$' is resolved to a cog address having difficulty with the multiple compile passes caused when you use @@@. Very, very obscure. It's also likely to take me a while to fix as I think I need to completely re-think how I've been doing '$' in the DAT block.
In the mean time.. "Don't do that".
The compiler is bunking out of the DAT block early with an error, but it's writing a completely bogus header in the object which causes the linker to chase its tail. So we know where the lockup is coming from now. Let me get a handle on this and I'll get back to you with a fix as soon as I can.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Actually, it turns out it's much simpler than that.
When you use @@@ the compiler does multiple complete passes of all the blocks to ensure everything is properly shuffled and positioned where it should be (usually 3 passes but for really complex interactions it can use more). This is the same loop algorithm that gets instigated when redundant method removal is activated to ensure that every possible unused method is removed (to make sure called references get chucked also).
The first pass runs through ok as the values used for @@@ are guessed. The first pass also aborts if there is an error. The following passes assumed there would be no compile errors as it passed checking in the first pass. In the case of space calculations with @@@ this is obviously incorrect, as when the proper values are substituted the calculation overflows and tries to allocate masses of RAM. This is a failure in the second pass that the compiler is not aborting on, and so it writes an invalid block header which ties the linker in a knot.
I have a fix for it but I need to QA it properly before I push it out.
In any case, a really neat bug. Thanks for giving me a nice, easy to reproduce test case!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
As you describe it, the test case could have been way smaller. I'm glad to help. Now thinking of it, I tested that aligment code in the opened file without creating a new one... something I normally do.
Ale said...
As you describe it, the test case could have been way smaller.
Probably, but I'd suggest it takes me far less time to zero in on the problem with a huge test case than it would take you to pare down the test case to a minimum. Bandwidth is cheap, time - not so much [noparse]:)[/noparse]
I've got it fixed, I just need to spark up my PPC Mac tonight and run some regression tests (it's old and frail so things take a bit longer. I know how it feels some days!)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
I have just loaded in BST 0.18.4 which reports compiler 0.15.3 and tried to compile Zicog010_demo_rr107 from Cluso's post. It gets no further than the first #else statement at the end of the firts CON block and throws an "expected unique name or ..." error .
All clues gratefully received.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
jazzed said...
Brad, Have you or anyone started a manual for BSTC yet? I'm specifically interested in preprocessor usage #ifdef, etc... Is it summarized anywhere?
No, nothing really outside of this thread.
The Preprocessor is pretty basic.
#define, #undef, #ifdef, #ifndef, #elseifdef, #elseifndef, #else, #endif
Symbols must be one contiguous statement of any length with no spaces. "this.is-a+valid,symbol" "this is not"
#error, #warn, #info simply take the following string and insert it as required. Spaces are ok.
All preprocessor defines must start in column 0 and can be nested to any number of levels. There is no limit to the number of preprocessor constructs, although lots of them makes for pretty bletcherous code.
There is no substitution, evaluation or math, it's simply either the symbols is defined or it's not.
In bst you can define symbols in the project file. With bstc you can define them on the command line.
All symbols are defined globally and passed down to sub-objects down the tree.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Thanks for that, documentation is not one of my stronger points.
Oh, and I have not forgotten about you Ale, I've just been waiting until I picked up my copy of OSX 10.6 (this morning) so I can do an install and verify on that also.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Thanks guys. I did not see a link to the BST Wiki in the first post. If it's there, it should be "highlighted in some flamboyant color."
Some time ago I found that I could use the C-preprocessor with the Propeller tool if I used brace comments. Having some built-in facility is much better of course.
Ale said...
I also wasted some money on 10.6... why did I buy it again ?...
BST works, I did not test programming yet.
I didn't waste any money on it... <cough> but I've not had a chance to install it yet.
To be honest I'm still happy with 10.4 but I support 10.5 and I'll try and support 10.6. To be honest I only boot/use OSX to support bst[noparse][[/noparse]cl], otherwise I spend all of my time in Linux. I boot windows for pre-release testing, but it involves borrowing a laptop as I don't own a copy myself.
@jazzed. There is no wiki link in the first post. I'll put one in there when I next update it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
When I fire up bst I get this little white vertical 1 by about 20 pixels tall line that shows up in the upper left of my screen on every desktop. What is that?
When I fire up bst I get this little white vertical 1 by about 20 pixels tall line that shows up in the upper left of my screen on every desktop. What is that?
Thanks,
Doug
I have no idea. Can you get a screenshot of it please?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Programming in 10.6 works very well. At least something still works (applications in general, I mean).
Thanks Ale [noparse]:)[/noparse] I actually had a chance to install 10.6 late this afternoon, but I did not have a chance to even load or test bst. Oh well, it's installed now, I wonder if it's worth purchasing or if I should go back to 10.5. Time will tell I guess [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Excellent. Can reproduce here. Thanks [noparse]:)[/noparse]
I found another odd one this morning. The Parallax compiler disallows either org or res to be more than $1F0. I accidentally made a cog variable res $1FFF instead of long $1FFF and could not figure out why bst kept complaining the source parameter was greater than $1FF.
mov dira, ee_test
ee_fred res $1FF <-- res was supposed to be long
ee_test res 1
Took me a while to nut out what was going on there.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Problem: Any defines in a projects options do not get cleared when the project is closed.
Lets say:
1) I have a project open with some defines specified in the project options. Everything builds and runs fine.
2) I close all files and I close that project.
3) I open a new top level spin file (not a project) that just happens to have the same defines as the project I just closed but now as "#define" statements.
Now compilation fails with "bla bla already defined errors"
Seems that when closing a project any defines it had in its project options remain in force.
This is kind of confusing and/or dangerous as one no longer knows which version of code is being built.
To find out one has to save the current work as a project and then check the defines in its options.
Now, while doing all this it happens that the defines get replicated in the project options dialog possibly many times.
Can't really post any code to show this effect.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
Problem: Any defines in a projects options do not get cleared when the project is closed.
heater said...
Now, while doing all this it happens that the defines get replicated in the project options dialog possibly many times.
Wow, 2 bugs in one report! Well done indeed.
I was not clearing the project defines on project close, and if there were any lingering they simply got appended to when opening a new project with defines!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
I forgot to declare a local variable, and forgot the "from" keyword on a repeat loop. Now it compiles [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full Morpheus & Mem+dual Prop SBC w/ 512KB kit $119.95, 2MB memory IO board kit $89.95, both kits $189.95 www.mikronauts.com - my site 6.250MHz custom Crystals for running Propellers at 100MHz Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
Post Edited (Bill Henning) : 9/21/2009 6:03:06 PM GMT
I worked around it and here is the code that busts if c1 and c2 are called just c
PUB SetPalette(yp,clr,r,g,b)
byte[noparse][[/noparse]@colors[noparse][[/noparse]yp]][noparse][[/noparse]clr]:=((r&7)<<5)+((g&7)<<2)+(b&3)
PUB SetPaletteRange(y1,y2,c2,r,g,b)|iy
repeat iy from y1 to y2
SetPalette(iy,c2,r,g,b)
PUB FillPalette(c1,r,g,b)
SetPaletteRange(0,yrez-1,c1,r,g,b)
I also have a global called 'c' that is declared in the DAT section at the end of the file.
It almost appears like it used the global instead of the argument to the method when generating code.
The other issue was that it hung when compiling an object when I forgot the "from" keyword
ie
repeat y 0 to 10
instead of
repeat y from 0 to 10
Hope this helps!
BradC said...
Bill Henning said...
I worked around the problem.
I forgot to declare a local variable, and forgot the "from" keyword on a repeat loop. Now it compiles [noparse]:)[/noparse]
Worked around what problem? Is there a bug I need to fix?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full Morpheus & Mem+dual Prop SBC w/ 512KB kit $119.95, 2MB memory IO board kit $89.95, both kits $189.95 www.mikronauts.com - my site 6.250MHz custom Crystals for running Propellers at 100MHz Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
Bill Henning said...
I worked around it and here is the code that busts if c1 and c2 are called just c
PUB SetPalette(yp,clr,r,g,b)
byte[noparse][[/noparse]@colors[noparse][[/noparse]yp]][noparse][[/noparse]clr]:=((r&7)<<5)+((g&7)<<2)+(b&3)
PUB SetPaletteRange(y1,y2,c2,r,g,b)|iy
repeat iy from y1 to y2
SetPalette(iy,c2,r,g,b)
PUB FillPalette(c1,r,g,b)
SetPaletteRange(0,yrez-1,c1,r,g,b)
I also have a global called 'c' that is declared in the DAT section at the end of the file.
It almost appears like it used the global instead of the argument to the method when generating code.
That is precisely what it did. When I modified the compiler for multi-pass compiles (for the @@@ keyword and unused object removal), I made a blue which allowed you to declare a local variable with the same name as a global variable. The compiler searches the global variable table first and so that is what it would have inserted.
I stumbled across this not too long ago myself and so it's fixed in my local tree.
Bill Henning said...
The other issue was that it hung when compiling an object when I forgot the "from" keyword
Yeah, heater pointed that one out to me a couple of weeks ago. It was more sinister than it looked.
I have to apologize in that both those bugs are already fixed in my local tree, but I've been lax in getting an updated release out.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Comments
Are you using 0.18.4? I'm trying to figure out why it's hanging for a while and I'm stumped.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
here is the code that hangs bst 0.18.4 on Mac OS X and bstc 0.15- It is basically the same error as before (@label - @@@label).
The other one... well is lost as I do not remember what I wrote, it could have been a typo, sorry. Next time I'll check twice or trice.
I'd create an archive but it does not compile ...
Thanks !!!
Edit: file removed
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
Post Edited (Ale) : 8/27/2009 11:24:09 AM GMT
Whoooooooooeeeeeeeee what a bug. This one only occurs if you are using '$' in your assembler AND you use @@@ somewhere in the same program. It's caused by a bug in the way '$' is resolved to a cog address having difficulty with the multiple compile passes caused when you use @@@. Very, very obscure. It's also likely to take me a while to fix as I think I need to completely re-think how I've been doing '$' in the DAT block.
In the mean time.. "Don't do that".
The compiler is bunking out of the DAT block early with an error, but it's writing a completely bogus header in the object which causes the linker to chase its tail. So we know where the lockup is coming from now. Let me get a handle on this and I'll get back to you with a fix as soon as I can.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
When you use @@@ the compiler does multiple complete passes of all the blocks to ensure everything is properly shuffled and positioned where it should be (usually 3 passes but for really complex interactions it can use more). This is the same loop algorithm that gets instigated when redundant method removal is activated to ensure that every possible unused method is removed (to make sure called references get chucked also).
The first pass runs through ok as the values used for @@@ are guessed. The first pass also aborts if there is an error. The following passes assumed there would be no compile errors as it passed checking in the first pass. In the case of space calculations with @@@ this is obviously incorrect, as when the proper values are substituted the calculation overflows and tries to allocate masses of RAM. This is a failure in the second pass that the compiler is not aborting on, and so it writes an invalid block header which ties the linker in a knot.
I have a fix for it but I need to QA it properly before I push it out.
In any case, a really neat bug. Thanks for giving me a nice, easy to reproduce test case!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
Probably, but I'd suggest it takes me far less time to zero in on the problem with a huge test case than it would take you to pare down the test case to a minimum. Bandwidth is cheap, time - not so much [noparse]:)[/noparse]
I've got it fixed, I just need to spark up my PPC Mac tonight and run some regression tests (it's old and frail so things take a bit longer. I know how it feels some days!)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
All clues gratefully received.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Do check the "Non-Parallax compatible extensions" and "Override global compiler optimizations" in the Project options dialogue.
Report back to the TriBlade thread.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
No, nothing really outside of this thread.
The Preprocessor is pretty basic.
#define, #undef, #ifdef, #ifndef, #elseifdef, #elseifndef, #else, #endif
Symbols must be one contiguous statement of any length with no spaces. "this.is-a+valid,symbol" "this is not"
#error, #warn, #info simply take the following string and insert it as required. Spaces are ok.
All preprocessor defines must start in column 0 and can be nested to any number of levels. There is no limit to the number of preprocessor constructs, although lots of them makes for pretty bletcherous code.
There is no substitution, evaluation or math, it's simply either the symbols is defined or it's not.
In bst you can define symbols in the project file. With bstc you can define them on the command line.
All symbols are defined globally and passed down to sub-objects down the tree.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
propeller.wikispaces.com/Mac+and+Linux+native+development
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
Thanks for that, documentation is not one of my stronger points.
Oh, and I have not forgotten about you Ale, I've just been waiting until I picked up my copy of OSX 10.6 (this morning) so I can do an install and verify on that also.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
BST works, I did not test programming yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
"highlighted in some flamboyant color."
Some time ago I found that I could use the C-preprocessor with the Propeller tool if I used brace comments. Having some built-in facility is much better of course.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
- Propalyzer: Propeller PC Logic Analyzer
- BMA: An on-chip PASM Debugger
- SPUD: Spin Source Level Debugger
Post Edited (jazzed) : 9/4/2009 4:40:55 PM GMTI didn't waste any money on it... <cough> but I've not had a chance to install it yet.
To be honest I'm still happy with 10.4 but I support 10.5 and I'll try and support 10.6. To be honest I only boot/use OSX to support bst[noparse][[/noparse]cl], otherwise I spend all of my time in Linux. I boot windows for pre-release testing, but it involves borrowing a laptop as I don't own a copy myself.
@jazzed. There is no wiki link in the first post. I'll put one in there when I next update it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
When I fire up bst I get this little white vertical 1 by about 20 pixels tall line that shows up in the upper left of my screen on every desktop. What is that?
Thanks,
Doug
I have no idea. Can you get a screenshot of it please?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Programming in 10.6 works very well. At least something still works (applications in general, I mean).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
Thanks Ale [noparse]:)[/noparse] I actually had a chance to install 10.6 late this afternoon, but I did not have a chance to even load or test bst. Oh well, it's installed now, I wonder if it's worth purchasing or if I should go back to 10.5. Time will tell I guess [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
The following hangs the compiler
BST 0.18.4
Compiler 0.15.3
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Excellent. Can reproduce here. Thanks [noparse]:)[/noparse]
I found another odd one this morning. The Parallax compiler disallows either org or res to be more than $1F0. I accidentally made a cog variable res $1FFF instead of long $1FFF and could not figure out why bst kept complaining the source parameter was greater than $1FF.
Took me a while to nut out what was going on there.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Same versions, same Debian Lenny.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Lets say:
1) I have a project open with some defines specified in the project options. Everything builds and runs fine.
2) I close all files and I close that project.
3) I open a new top level spin file (not a project) that just happens to have the same defines as the project I just closed but now as "#define" statements.
Now compilation fails with "bla bla already defined errors"
Seems that when closing a project any defines it had in its project options remain in force.
This is kind of confusing and/or dangerous as one no longer knows which version of code is being built.
To find out one has to save the current work as a project and then check the defines in its options.
Now, while doing all this it happens that the defines get replicated in the project options dialog possibly many times.
Can't really post any code to show this effect.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Wow, 2 bugs in one report! Well done indeed.
I was not clearing the project defines on project close, and if there were any lingering they simply got appended to when opening a new project with defines!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I forgot to declare a local variable, and forgot the "from" keyword on a repeat loop. Now it compiles [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheus & Mem+dual Prop SBC w/ 512KB kit $119.95, 2MB memory IO board kit $89.95, both kits $189.95
www.mikronauts.com - my site 6.250MHz custom Crystals for running Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
Post Edited (Bill Henning) : 9/21/2009 6:03:06 PM GMT
Worked around what problem? Is there a bug I need to fix?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
PUB SetPalette(yp,clr,r,g,b) byte[noparse][[/noparse]@colors[noparse][[/noparse]yp]][noparse][[/noparse]clr]:=((r&7)<<5)+((g&7)<<2)+(b&3) PUB SetPaletteRange(y1,y2,c2,r,g,b)|iy repeat iy from y1 to y2 SetPalette(iy,c2,r,g,b) PUB FillPalette(c1,r,g,b) SetPaletteRange(0,yrez-1,c1,r,g,b)I also have a global called 'c' that is declared in the DAT section at the end of the file.
It almost appears like it used the global instead of the argument to the method when generating code.
The other issue was that it hung when compiling an object when I forgot the "from" keyword
ie
repeat y 0 to 10
instead of
repeat y from 0 to 10
Hope this helps!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheus & Mem+dual Prop SBC w/ 512KB kit $119.95, 2MB memory IO board kit $89.95, both kits $189.95
www.mikronauts.com - my site 6.250MHz custom Crystals for running Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
That is precisely what it did. When I modified the compiler for multi-pass compiles (for the @@@ keyword and unused object removal), I made a blue which allowed you to declare a local variable with the same name as a global variable. The compiler searches the global variable table first and so that is what it would have inserted.
I stumbled across this not too long ago myself and so it's fixed in my local tree.
Yeah, heater pointed that one out to me a couple of weeks ago. It was more sinister than it looked.
I have to apologize in that both those bugs are already fixed in my local tree, but I've been lax in getting an updated release out.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?