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

feat: write (simple) zk_evm assembly VSCode extension #299

Open
Nashtare opened this issue Jun 18, 2024 · 6 comments
Open

feat: write (simple) zk_evm assembly VSCode extension #299

Nashtare opened this issue Jun 18, 2024 · 6 comments
Assignees
Labels
enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed

Comments

@Nashtare
Copy link
Collaborator

This had been discussed a few times in the past, but never really shared to a greater audience through an actual issue.

The idea is to write a simple extension to allow new & external contributors / auditors an easier onboarding into the KERNEL assembly code. It would also make the life of current maintainers easier.

We probably don't need a fancy extension, just one that would support:

  • documentation highlight upon hovering macros / global labels
  • automatic redirection to macros / global labels

@BGluth noticed this may even be doable in Rust.

@Nashtare Nashtare added enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed labels Jun 18, 2024
@Nashtare Nashtare modified the milestone: Cleanups and Misc. Jun 21, 2024
@Nashtare Nashtare added this to the System strengthening milestone Jul 16, 2024
@0xaatif
Copy link
Contributor

0xaatif commented Sep 6, 2024

What is "KERNEL assembly code"?

Is it a polygon invention? Is there a standard anywhere?

@hratoanina
Copy link
Contributor

This is the assembly language used in all the .asm files of the kernel, e.g. here.
The syntax is, as far as know, in-house, but according to a comment loosely based on this.

@Nashtare
Copy link
Collaborator Author

Nashtare commented Sep 6, 2024

The custom syntax Hamy mentioned is defined here: evm_arithmetization/src/cpu/kernel/evm_asm.pest

@Nashtare Nashtare pinned this issue Sep 6, 2024
@Nashtare
Copy link
Collaborator Author

@0xaatif assigning you this following what you shared on Monday for tracking

@0xaatif
Copy link
Contributor

0xaatif commented Sep 29, 2024

I've done a brief spike on this this week, culminating in a working syntax highlighting prototype.
It'll need a little work to actually get into our repo and be usable.

Documentation highlighting is probably doable.
Go to definition won't work without rewriting our AST representation to actually track source spans.

If we're serious about the above work I can come up with a plan and sizing, and we can prioritise accordingly.

@Nashtare
Copy link
Collaborator Author

Nashtare commented Oct 2, 2024

Originally posted under #674:

Thanks Aatif, I just installed and tested the extension from #674, it does highlight the comments properly as expected!
As a reference, I was previously using Arm Assembly extension (dan-c-underwood.arm) which, even though not quite adequate, is doing enough for the eyes at least.

Ideally, the long term goal of such extension would be the common convenient features offered by others.
On the top of my mind, the two main ones would be:

  • documentation preview: maybe 60% of the global FOO labels and %macro BAR are documented with ///, which would be great if we could highlight these upon mouse hovering in other locations. This is probably the biggest need, especially for external contributors / auditors who have a hard time grasping everything around / navigating through the 1000s lines of code.
  • distinct highlighting: for visual convenience, differentiating say opcodes (PUSH / DUP4), labels, macros, conditional blocks. Probably the easiest to have on top of the existing I would guess?
  • definition redirection: really nice to have, but not highest priority, i.e. click + redirection to label / macro def location. Super convenient when going through the flow and hitting a %jump(FOO).

If you think these are doable (with or without parser refactoring), feel free to layout the iterative steps to achieve them in some tickets. The priority is definitely not as high as getting the cdk-erigon type2 up and running, but would still be really great to have.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed
Projects
Status: In Progress
Development

No branches or pull requests

3 participants