Well, I got bitten by this one again today. It's not a bug, but just an annoyance that kept me going in circles for a couple hours, until I remembered the last time it reared its ugly head.
In the body of a program, one can use either 0b10101010 or b'10101010' for instance, and similarly for hexadecimal.
BUT, when declaring a constant (using #DEFINE) only the latter format with apostrophes is acceptable. The code will compile with no notification of errors, but in fact was is compiled will be incorrect. Unfortunately, this is one of those things that is easy to not notice when debugging the program.
Grrr...
Thomas Henry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was thinking of writing a parser to help us fix these types of issues, then, when we have a bunch of issues fixed in the parser we can move to the main code base.
I know of a few place where a 'space' can confuse, and, where a missing parameter can confuse also.
I was also thinking of adding some 'system' parameter substitutions. This would support inserting dates\revision level\dates into the code to aid the development process.
The question is... Is this worth the effort?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the long run, it probably is worth the effort to put a proper lexer/parser onto GCBASIC. Way back now (circa 2007-2008) I created a new lexer that was able to turn a program into nicely analysed tokens, and started on a parser to try and form it into a parse tree. It never really progressed beyond an experiment, but I've attached what I do have. Lots of hard coded paths in there, but it could be quite a good thing to transplant onto the existing compiler.
The code in the zip file was meant to be the start of a major rewrite of GCBASIC, but it would have caused a ton of compatibility problems and probably added an extra few years of bug fixing! In in about Feb 2009 I made some major changes to the way that subroutines are handled, which broke the compiler pretty thoroughly for about 4 months. Not keen to have a repeat of that, gradual changes are far easier to deal with!
I'm thinking that for now, I/we should probably try to combine the new lexer with the preprocessor routine in GCBASIC, so that when it loads the program, it also generates a list of tokens for each line. Then various parts of the compiler can be changed over gradually to work with the tokens rather than the strings it has read in. These problems with constants would be nicely cured with the new lexer, and it would be somewhat easier to add support for some other nice things like floating point or user defined types in future.
I'll see if I can create an easy fix for these silly constant problems for now, and hopefully can spend some time doing major things to GCBASIC in a month or so.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2013-10-16
Well, if the parser is going to be revamped, I think it would be very useful to permit $FF for hex and #10101010 for binary. I find the apostrophe notation awkward and slow. But banging out a hex or binary number is so fast and easy when only a single character is needed to indicate the base.
Thomas Henry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had a similar issue at the weekend. I was using #SYMBOL rather than #DEFINE.... an error caused by moving from one toolset to GCB.
Compiled fine but I had run time errors. Basically, I had uninitialised string variable not the integers I was expected.
As a result I created this test program to enable to review the ASM file. This shows the correct syntax for defining constants.
#chip 16F88, 4
#config Osc = INT, MCLRE_OFF
' All these work
#define Test0 b'11111111'
#define Test1 0b11111111
#define Test2 0B11111111
#define Test3 255
#define Test4 0xFF
#define Test5 0xff
#define Test6 h'ff'
dir porta Out
porta = test0
porta = test1
porta = test2
porta = test3
porta = test4
porta = test5
porta = test6
End
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This forum is for any Great Cow Basic related discussion - help with
projects, general advice.
Advertising or spamming is not permitted. Messages that are advertising or
deemed to be spammed will be deleted and/or closed.
These forums are intended to facilitate the flow of useful, appropriate and
fun information about the Great Cow Basic solution for the programming of
microcomputers. Show respectful to others and please treat others how you
would like to be treated.
Please remember many readers will read your messages. Some of these readers
may not have English as a first language, or they may potentially be school
students with little electronics knowledge and others may be more mature
with years of experience. Respect each other's experience and/or lack of
knowledge. Be concise and as accurate as possible in message. Avoid use of
abbreviations and long program posting where ever possible.
Please check the FAQ in this forum, and then complete a search before
starting a new thread. The Great Cow Basic manuals are available here:
If you add any Great Cow Basic program code to your post, please enclose it
within five tildes \~~~~~ at the start and end of you code and a hard space
at the start of each line of your code. Other formatting tags are available,
please see the formatting help.
Finally, if you attach an image, please make sure it is a small, low
resolution file.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi gang,
Well, I got bitten by this one again today. It's not a bug, but just an annoyance that kept me going in circles for a couple hours, until I remembered the last time it reared its ugly head.
In the body of a program, one can use either 0b10101010 or b'10101010' for instance, and similarly for hexadecimal.
BUT, when declaring a constant (using #DEFINE) only the latter format with apostrophes is acceptable. The code will compile with no notification of errors, but in fact was is compiled will be incorrect. Unfortunately, this is one of those things that is easy to not notice when debugging the program.
Grrr...
Thomas Henry
I was thinking of writing a parser to help us fix these types of issues, then, when we have a bunch of issues fixed in the parser we can move to the main code base.
I know of a few place where a 'space' can confuse, and, where a missing parameter can confuse also.
I was also thinking of adding some 'system' parameter substitutions. This would support inserting dates\revision level\dates into the code to aid the development process.
The question is... Is this worth the effort?
In the long run, it probably is worth the effort to put a proper lexer/parser onto GCBASIC. Way back now (circa 2007-2008) I created a new lexer that was able to turn a program into nicely analysed tokens, and started on a parser to try and form it into a parse tree. It never really progressed beyond an experiment, but I've attached what I do have. Lots of hard coded paths in there, but it could be quite a good thing to transplant onto the existing compiler.
The code in the zip file was meant to be the start of a major rewrite of GCBASIC, but it would have caused a ton of compatibility problems and probably added an extra few years of bug fixing! In in about Feb 2009 I made some major changes to the way that subroutines are handled, which broke the compiler pretty thoroughly for about 4 months. Not keen to have a repeat of that, gradual changes are far easier to deal with!
I'm thinking that for now, I/we should probably try to combine the new lexer with the preprocessor routine in GCBASIC, so that when it loads the program, it also generates a list of tokens for each line. Then various parts of the compiler can be changed over gradually to work with the tokens rather than the strings it has read in. These problems with constants would be nicely cured with the new lexer, and it would be somewhat easier to add support for some other nice things like floating point or user defined types in future.
I'll see if I can create an easy fix for these silly constant problems for now, and hopefully can spend some time doing major things to GCBASIC in a month or so.
Well, if the parser is going to be revamped, I think it would be very useful to permit $FF for hex and #10101010 for binary. I find the apostrophe notation awkward and slow. But banging out a hex or binary number is so fast and easy when only a single character is needed to indicate the base.
Thomas Henry
To set expectations. Revamping the parser is the goal. It may take some time.
:-)
I had a similar issue at the weekend. I was using #SYMBOL rather than #DEFINE.... an error caused by moving from one toolset to GCB.
Compiled fine but I had run time errors. Basically, I had uninitialised string variable not the integers I was expected.
As a result I created this test program to enable to review the ASM file. This shows the correct syntax for defining constants.
Excellent. Thanks.
btw,
How do your get your code to post properly with the # symbol?
Chuck,
I am writing a number of FAQ's for the forum. We will soon have a new read
only forum for FAQ and readme files.
This is a draft of the first readme files, see below.
The method to post code is stated in this read me.
Welcome to the Great Cow Basic forum at
https://sourceforge.net/p/gcbasic/discussion/
This forum is for any Great Cow Basic related discussion - help with
projects, general advice.
Advertising or spamming is not permitted. Messages that are advertising or
deemed to be spammed will be deleted and/or closed.
These forums are intended to facilitate the flow of useful, appropriate and
fun information about the Great Cow Basic solution for the programming of
microcomputers. Show respectful to others and please treat others how you
would like to be treated.
Please remember many readers will read your messages. Some of these readers
may not have English as a first language, or they may potentially be school
students with little electronics knowledge and others may be more mature
with years of experience. Respect each other's experience and/or lack of
knowledge. Be concise and as accurate as possible in message. Avoid use of
abbreviations and long program posting where ever possible.
Please check the FAQ in this forum, and then complete a search before
starting a new thread. The Great Cow Basic manuals are available here:
If you add any Great Cow Basic program code to your post, please enclose it
within five tildes \~~~~~ at the start and end of you code and a hard space
at the start of each line of your code. Other formatting tags are available,
please see the formatting help.
Finally, if you attach an image, please make sure it is a small, low
resolution file.