It would appear that FOR loops are always executed once, regardless of the start and end values. For example:
endval = 2
FOR var = 1 TO endval - 2
; this gets executed
NEXT
(I appreciate that this is not necessarily a compiler problem but if the behaviour is intended/expected it might be worth a line in the Help for FOR to that effect.)
Also, it would seem that the compiler doesn't evaluate expressions when assigning values to arrays. So, for example
#define OFFSET 10
outbuf(1 + OFFSET) = 99
gives "10 not a variable" error
Again, not necessarily a compiler problem but it would be nice to be able to do (this one probably belongs in the "feature request" thread rather than as a "problem").
And to return to my theme of logical expressions…
#define OK_TO_WRITE PORTA.3
IF NOT OK_TO_WRITE THEN
My syntax is completely wrong, of course (I should be testing IF OK_TO_WRITE OFF THEN) but I just thought I'd mention it for completeness.
I'm not here to nitpick (honest!). Great Cow BASIC is an outstanding piece of work and the programs I've completed in a few days would have taken me weeks in assembler. I'm only posting in case these issues are of interest to you.
Mark
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The For thing wasn't quite a bug - I'd made it that way deliberately to save on code space. However, I'd been rethinking it lately, and on second thoughts it's not worth causing bother to save 14 bits of memory. For should now check before entering the loop, as it does in other BASIC dialects.
I couldn't duplicate the array error, it's possibly (a) something that I've already fixed or (b) something caused by something else in your program. If the update doesn't fix it, can you please post a complete program that has the problem?
The condition bug is related to the one you came across with the AND. GCBASIC was properly handling conditions with a single comparison, or with multiple comparisons and AND/OR/NOT/etc operations, but not those with only a single non-comparison operator. The update should fix this.
And don't worry about nitpicking, the smaller bugs can be just as annoying as the big ones and need to be fixed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The mention of the issue with REPEAT in the release notes for this update explains a problem I had in the D22-5003 graphical LCD code that I posted a couple of weeks ago which rather confused me at the time.
I will load the update and give the array issue another try in the next week or two. If I can reproduce it craft a small program to demonstrate it (the code where I found the issue is several hundred lines long and I didn't want to post/email something that big).
As you say, the FOR behaviour is not exactly a bug but it's a lot more convenient to have it behave the way that other dialects of BASIC do. Though it might add a few extra bytes of program code in some circumstances in other cases it is no longer necessary to add an IF to prevent the FOR loop being executed if the end value is smaller than the start value, so it probably balances out :-)
Thanks again!
Mark
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anyway I,m sort of neutral on the change. Increase in overhead for 10f's on the order of 5-10% for blinky rgb led.
There is one problem though, not getting a carry on the new for/next statements. Can be tested when specifying for blink = 1 to 255…next (doesn't work). This works when for blink = 1 to 254…next.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
EDIT: RE: the previous code, the implication was that the BlinkPeriod was initialized as BlinkPeriod = 0, but the for/next still runs. Not a huge deal to initialize BlinkPeriod = 1.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It would appear that FOR loops are always executed once, regardless of the start and end values. For example:
endval = 2
FOR var = 1 TO endval - 2
; this gets executed
NEXT
(I appreciate that this is not necessarily a compiler problem but if the behaviour is intended/expected it might be worth a line in the Help for FOR to that effect.)
Also, it would seem that the compiler doesn't evaluate expressions when assigning values to arrays. So, for example
#define OFFSET 10
outbuf(1 + OFFSET) = 99
gives "10 not a variable" error
Again, not necessarily a compiler problem but it would be nice to be able to do (this one probably belongs in the "feature request" thread rather than as a "problem").
And to return to my theme of logical expressions…
#define OK_TO_WRITE PORTA.3
IF NOT OK_TO_WRITE THEN
Produces the following assembler:
My syntax is completely wrong, of course (I should be testing IF OK_TO_WRITE OFF THEN) but I just thought I'd mention it for completeness.
I'm not here to nitpick (honest!). Great Cow BASIC is an outstanding piece of work and the programs I've completed in a few days would have taken me weeks in assembler. I'm only posting in case these issues are of interest to you.
Mark
There is now a new update, which hopefully will fix these problems. The link for the update is at http://gcbasic.sourceforge.net/update.html
The For thing wasn't quite a bug - I'd made it that way deliberately to save on code space. However, I'd been rethinking it lately, and on second thoughts it's not worth causing bother to save 14 bits of memory. For should now check before entering the loop, as it does in other BASIC dialects.
I couldn't duplicate the array error, it's possibly (a) something that I've already fixed or (b) something caused by something else in your program. If the update doesn't fix it, can you please post a complete program that has the problem?
The condition bug is related to the one you came across with the AND. GCBASIC was properly handling conditions with a single comparison, or with multiple comparisons and AND/OR/NOT/etc operations, but not those with only a single non-comparison operator. The update should fix this.
And don't worry about nitpicking, the smaller bugs can be just as annoying as the big ones and need to be fixed.
Thanks for the very prompt fixes!
The mention of the issue with REPEAT in the release notes for this update explains a problem I had in the D22-5003 graphical LCD code that I posted a couple of weeks ago which rather confused me at the time.
I will load the update and give the array issue another try in the next week or two. If I can reproduce it craft a small program to demonstrate it (the code where I found the issue is several hundred lines long and I didn't want to post/email something that big).
As you say, the FOR behaviour is not exactly a bug but it's a lot more convenient to have it behave the way that other dialects of BASIC do. Though it might add a few extra bytes of program code in some circumstances in other cases it is no longer necessary to add an IF to prevent the FOR loop being executed if the end value is smaller than the start value, so it probably balances out :-)
Thanks again!
Mark
For every action there is a reaction. This worked perfectly well before:
Anyway I,m sort of neutral on the change. Increase in overhead for 10f's on the order of 5-10% for blinky rgb led.
There is one problem though, not getting a carry on the new for/next statements. Can be tested when specifying for blink = 1 to 255…next (doesn't work). This works when for blink = 1 to 254…next.
EDIT: RE: the previous code, the implication was that the BlinkPeriod was initialized as BlinkPeriod = 0, but the for/next still runs. Not a huge deal to initialize BlinkPeriod = 1.