Replies: 3 comments 1 reply
-
Turns out treating ca65 as a context-free grammar is really tricky. Consider an example: .macro ldax _a, _x
lda _a
ldx _x
.endmacro
start ldax _a, _x ; In this case, parser can infer that "start" is a colon-less label
; and ldax is a macro thanks to the operands However, there are cases when it's impossible to unambiguously infer the terms: .macro pushall
pha
phx
phy
.endmacro
start pushall ; start - label, pusha - macro, or...
; start - macro, pusha - operand
; we humans can see that it's the former, but the parser doesn't. At this point, colon-less labels become a real pain, since they make the grammar impossible to parse without ambiguities. |
Beta Was this translation helpful? Give feedback.
-
There aren't many serious programming languages that are context free. This is also true for ca65. Maybe it's possible to duplicate the logic that ca65 uses when parsing a line. The relevant source code can be found here. |
Beta Was this translation helpful? Give feedback.
-
I've been working on a tree-sitter grammar for ca65 for a little while. The grammar itself is a mess and definitely still a work in progress, but is nearly feature complete. Might be of use. |
Beta Was this translation helpful? Give feedback.
-
I've recently started working on a code formatter for ca65 assembly that I called
nice65
.It is rather primitive at this time (for example, it cannot yet "understand" macros, which is an entire beast on its own!)
I'm also focusing on 65(c)02 instruction set at this time.
I'm using Lark (Python) as a parser library, but am considering an option of switching to Go for better portability & performance.
Even though I was able to make
nice65
work well with C64 Kernal/BASIC sources and some other projects ("work well" == "prettify the code and not break anything"), it's still very far from perfect since it only covers the mostly used subset of features, and ca65 syntax has way more in its sleeve than I can imagine. Still, it's currently only around 200 SLOC and it's doing a relatively good job so far.I was wondering if anyone is aware of an existing EBNF definition (or similar) for valid ca65 assembly files, or maybe there's some parsing code within ca65 itself that I can port to (or use as a reference for writing) a function that will be able to parse any valid ca65 assembly into an abstract syntax tree. Of course, the former would be the best option, but I might be asking for too much. The latter is also an option, but I'm afraid it's going to exceed my mental abilities and time constraints.
My current naїve attempt on a grammar definition for
nice65
can be found here.Any thoughts and suggestions are welcome!
EDIT: Disclaimer: the set of formatting rules that I implemented in
nice65
are my personal preference. I'm planning to make indentation sizes, line breaks, etc all configurable. In fact, the formatting part itself is a breeze: the hardest part is gettingnice65
to first "understand" any valid ca65 assembly. Therefore adding more features (such as linting, warning about common pitfalls, etc) will also become possible, possibly in the scope of another tool.Beta Was this translation helpful? Give feedback.
All reactions