Literal indicator? I don't need no literal indicator!
wmosscrop
Posts: 409
Just spent several hours trying to figure out why I was getting strange results from my PASM code.
Tracked it down to this:
Which, of course, should have been:
The low-order bits of location %11111000 (248) were thus used to set the counter and pll options. Of course, adding and removing debug code changed the contents of this location... so it would work... then I'd make another change and it wouldn't work... and back and forth I went.
Lesson learned. Don't look at just JMP's and CALL's for missing literal indicators.
Walter
Tracked it down to this:
MOVI CTRB, %11111_000 ' Logic Always
Which, of course, should have been:
MOVI CTRB, #%11111_000 ' Logic Always
The low-order bits of location %11111000 (248) were thus used to set the counter and pll options. Of course, adding and removing debug code changed the contents of this location... so it would work... then I'd make another change and it wouldn't work... and back and forth I went.
Lesson learned. Don't look at just JMP's and CALL's for missing literal indicators.
Walter
Comments
I still get caught by that once in a while. For some reason I seem to have an ingrained habit of thinking that the more common 9 bit addresses should be the default instead of the register based ones. Not sure which uC assembler that idea comes from.
The first time you do it you tear your hair out trying to find the bug. And the second...and the third...even old hands get caught out.
Was't it BST that issued a warning about the lack of "#" ?
Dave, what other traps in Spin and PASM do you have in mind? First that comes to my mind is the "greater that or equal" and "less than or equal" comparison operators that are backward compared to C and many other languages. Little bombs waiting to blow the day of programmers used those languages.
Perhaps we should write a linter for Spin ?
If there is no a label name on the source side, it's a direct value.
If the direct value is above 511 it creates a pool for the numbers and inserts the location for it.
But code incompatible with different compilers is not nice, forcing you run it through "cleaner" for use with OEM complier.
Yes, the ">=" and "<=" operators are common problems for newbies, and even experienced Spin programmers. I've gotten caught by not having an ORG statement at the beginning of my PASM code when doing multiple COG programs in a file. I'm sure we could come up with a list of common errors.
Now, how does one write a Spin parser?
Where is the formal definition of Spin to make this possible?
I could get seriously lost in creating a parser for Spin using the pegjs parser generator, then we can do all this in the browser as well as the command line.
http://pegjs.org/
You never know, such a parser could grow into a compiler.