Error if "if bit1=5 then"?
- Thread starter Pekari
- Start date
mrburnette
Senior Member
Interestingly, the syntax checker does not give an error.
Code:
main:
If bit1 = 5 then finished
pause 100
goto main
finished:
end- Ray
hippy
Ex-Staff (retired)
It is possible for compilers to error on lines of code which make syntactical sense but don't make semantic sense but in most cases compilers will only catch syntax errors.
The notable exception for the PICAXE compilers is for "HIGH pin1" and similar where the outcome is most likely not what the writer intends, so there's a 'for the greater good' argument to label that an error even though it's syntactically correct and in some cases semantically correct as well. Some disagree with that decision.
There's never going to be agreement on what semantic issues to check for and such checks can rarely be comprehensive. If an 'all or nothing' case is best, 'halfway' isn't deemed good enough but 'all' is unattainable, it can be argued 'none' is the best state of affairs.
There's even an argument that such lines are not semantic errors, perhaps a deliberate attempt to cause the comparison to always fail ( for debugging or during code development ) and giving an error in that case means some other way has to be found which makes development more awkward.
No matter what's done there will be an argument which says that's wrong.
The notable exception for the PICAXE compilers is for "HIGH pin1" and similar where the outcome is most likely not what the writer intends, so there's a 'for the greater good' argument to label that an error even though it's syntactically correct and in some cases semantically correct as well. Some disagree with that decision.
There's never going to be agreement on what semantic issues to check for and such checks can rarely be comprehensive. If an 'all or nothing' case is best, 'halfway' isn't deemed good enough but 'all' is unattainable, it can be argued 'none' is the best state of affairs.
There's even an argument that such lines are not semantic errors, perhaps a deliberate attempt to cause the comparison to always fail ( for debugging or during code development ) and giving an error in that case means some other way has to be found which makes development more awkward.
No matter what's done there will be an argument which says that's wrong.
In this case the compiler doesn't check what the number is, as the firmware just looks at the lower bit of whatever that number may be to give a binary comparison. So it's always a 0 or 1 comparison, regardless of the number entered, so in this paricular case 5 is treated as 1.
