Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add language support for RP2040 PIO ASM #1056

Draft
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

willeccles
Copy link

Adds support for the PIO assembler language for the RP2040, including embedded C code. I have left the "detected" language from the embedded code snippets generic and hard-coded C for now, as it's possible they could add support for other languages (i.e., C++, Python) in the future. To accomplish this, I have included new patterns and language contexts and so on where necessary.

However, I did not know how to handle the fact that it's an error for a % c-sdk { to be unterminated by a matching %}. At the moment, it simply treats it the same as Markdown--unbalanced is just treated as a valid block. Feedback would be appreciated. Relevant code snippets: here and here.

@willeccles willeccles marked this pull request as draft January 2, 2024 23:57
@willeccles
Copy link
Author

willeccles commented Jan 3, 2024

Reproduction for the issue: consider a simple PIO program with the following code:

.program something
nop

% c-sdk {
void func(void);
// <---- code block NOT terminated!

The assembler will reject this program, but tokei will treat it the same way it does Markdown code fences: if it's not terminated, the rest of the file is C, and there is only one comment added for the % c-sdk {. This is technically correct in this situation, despite the program being ill-formed.

Now let's slightly tweak this file. If you simply start another PIO program underneath this, the counting is now broken:

.program something
nop

% c-sdk {
void func(void);
// <---- code block NOT terminated!

.program another_program
nop

This is also not accepted by the assembler, and again, tokei considers the rest of the file to be C code. However, in this example, this is not correct--this counts PIO instructions as C code.

I am not sure how this should be handled. Any thoughts? The question is really this: should tokei make an effort to properly handle ill-formed code? Personally, my vote is that this is probably "correct" behavior as-is. Garbage in, garbage out.

@willeccles
Copy link
Author

Just realized that Python is supported in passthrough sections as per datasheet section 3.3.10.2. I'll update to include that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant