Riscrithm – An intuitive RISC-V assembler and optimizer coded in Go(github.com)
github.com
Riscrithm – An intuitive RISC-V assembler and optimizer coded in Go
https://github.com/ghetea-patrick/riscrithm
14 comments
Hi Benji, sorry for the late reply. I saw you were really interested in it, and I hope my comment answers your questions. Strict macro checking (using the 'define' keyword) and register validation (including case checks to ensure consistent coding) will be implemented in version 2.0. Right now, it doesn’t strictly throw an error if a line is wrong in all contexts, but in the final assembly, the invalid lines won’t compile anyway. You’re right, and I’ll definitely include such checks in Riscrithm v2.0. Also, if you want to check out my new release, Riscrithm v1.1 is now available on GitHub.
For your second point, yes, RISC-V assemblers sometimes transform written assembly into their equivalent instructions (e.g., 'mv foo, bar' becomes 'addi foo, bar, 0'). Riscrithm uses normal RISC-V syntax (like 'ret' or 'nop' keywords rather than the true on-metal command). This doesn’t mean we lose assembly’s flexibility—commands are always as close to the metal as possible. Keywords like 'swap' of course expand into more lines of code, but these are always clear expansions the developer can understand and verify anytime. The goal of Riscrithm is to make writing assembly simpler and cleaner, which is why I focus on mapping instructions clearly to their true on-metal equivalents. If you want to see which instructions expand into what, you can check the Developer Manual, which now includes four Riscrithm v1.1 examples with their corresponding assembly. Again, great points and comments—I really appreciate them!
For your second point, yes, RISC-V assemblers sometimes transform written assembly into their equivalent instructions (e.g., 'mv foo, bar' becomes 'addi foo, bar, 0'). Riscrithm uses normal RISC-V syntax (like 'ret' or 'nop' keywords rather than the true on-metal command). This doesn’t mean we lose assembly’s flexibility—commands are always as close to the metal as possible. Keywords like 'swap' of course expand into more lines of code, but these are always clear expansions the developer can understand and verify anytime. The goal of Riscrithm is to make writing assembly simpler and cleaner, which is why I focus on mapping instructions clearly to their true on-metal equivalents. If you want to see which instructions expand into what, you can check the Developer Manual, which now includes four Riscrithm v1.1 examples with their corresponding assembly. Again, great points and comments—I really appreciate them!
> instead of a PDP 11 as the virtual machine, why not risc V
What would that look like, in your view? I can't see them being significantly different, as computation models go. And I'm familiar with both.
If you're thinking of ++ and --, those were introduced in the B language before the first PDP-11 was even made, plus of course the PDP-11 only offers pre-decrement and post-increment while C offers all four combinations.
What would that look like, in your view? I can't see them being significantly different, as computation models go. And I'm familiar with both.
If you're thinking of ++ and --, those were introduced in the B language before the first PDP-11 was even made, plus of course the PDP-11 only offers pre-decrement and post-increment while C offers all four combinations.
I'm not really sure. Problem is, is that a lot of the compressed instructions have been informed by the c way of doing things.
TBF I'm playing with a pi Pico, so anything I do is likely to be more influenced by the memory set up. Ie xip.
I could write a whole essay on this. But I was more meditating on the assumptions and decisions made, because that was obvious/easy given the hardware available. Why don't really write languages like that now, and I don't really think C is that language anymore. But it would be interesting to see what could emerge.
TBF I'm playing with a pi Pico, so anything I do is likely to be more influenced by the memory set up. Ie xip.
I could write a whole essay on this. But I was more meditating on the assumptions and decisions made, because that was obvious/easy given the hardware available. Why don't really write languages like that now, and I don't really think C is that language anymore. But it would be interesting to see what could emerge.
To answer this follow-up, Benji, the syntax was designed so the learning curve isn’t too steep for people coming from languages like C/C++, even if I think that analogy is wrong, Riscrithm isn’t trying to be another C, as that would just be a cheap and worse copy. My goal is to allow people writing drivers or high-performance code to focus on structuring their logic without the compiler abstracting it into ambiguous implementations. Also, it’s great seeing you using a Pico; working with microcontrollers is fantastic, and I think it would be nice if you considered running Riscrithm on it—especially v1.1. Let’s be honest, v1.0 was an MVP, while v1.1 aims to bring all the features that will appear in v2.0, which will largely improve the compiler’s structure and make the language cleaner. I also appreciate your curiosity about what might emerge, and I want to assure you that I’ll do my best to make it a great language!
>Riscrithm isn’t trying to be another C
I was more just musing on the space around high level assembler/ low level programming language. Currently C is the option. So anything entering that space will be competing with C
I was more just musing on the space around high level assembler/ low level programming language. Currently C is the option. So anything entering that space will be competing with C
Hi Benji, I tried to reply to your comment earlier, but it seems it didn’t go through, so I’m trying again to say that you’re right. I hope you enjoyed exploring (and maybe even using) Riscrithm. My goal was to make writing assembly cleaner while still giving developers full control. Sure, C is the standard now, but I hope Riscrithm can offer a fresh perspective on low-level coding.
Ah, so it's a so-called "high-level assembler" like PL/360 [0] for System/360 or PL-11 [1] for PDP-11? The problem with such languages is, well, C has killed them pretty thoroughly. You can take PCC, or LCC, or Tiny CC, and cobble a new instruction-emitter (for a relatively sane ISA) of decent quality in a week or so.
[0] https://en.wikipedia.org/wiki/PL360
[1] https://en.wikipedia.org/wiki/PL-11
[0] https://en.wikipedia.org/wiki/PL360
[1] https://en.wikipedia.org/wiki/PL-11
Thing is. Old C killed them, new c will use UB to optimize things that can't happen, like integer overflow checks.
C is no longer that high level assembler that killed the others.
Plus I think you're being overly negative. This is a very under explored space in modern computing. As someone one who likes to get down to the bits and bytes, this looks like an interesting proposition.
C is no longer that high level assembler that killed the others.
Plus I think you're being overly negative. This is a very under explored space in modern computing. As someone one who likes to get down to the bits and bytes, this looks like an interesting proposition.
Hi Joker_vD, I really appreciate the comment and you’re mostly right—C was meant to be a portable assembly language that abstracts developers from machine instructions. Riscrithm isn’t trying to be a worse copy of C; it would be impossible for a single developer to match it. Instead, Riscrithm is meant to make writing RISC-V assembly simpler while maintaining a 1:1 relationship between Riscrithm lines and assembly lines. When writing a driver, you often need to use assembly, and with Riscrithm, you know exactly what each line does and how it’s translated. In contrast, with C/C++ or others, a single line of code can expand into many more assembly lines. This is just v1.0.0 (which I wrote in my free time this weekend), and v1.1.0 is coming soon with better features—I hope you’ll check it out!
I should also apologize for the delay in my reply, but the time difference is quite the buzzkill!
Constructive cricitism: this would really benefit from a parsing layer and dealing with more abstract structures, rather than operating on strings and regular expressions.
I really hope this is not vibe coded, because my criticism, if this wasn’t the honest work of a beginner, would be much more scathing than that and would confirm all my biases against LLMs.
I really hope this is not vibe coded, because my criticism, if this wasn’t the honest work of a beginner, would be much more scathing than that and would confirm all my biases against LLMs.
Hi 'sph', sorry for the late reply, but I’ve been working on version 1.1. You’re absolutely right about cleaning up the code. Honestly, I’m not a Go programmer with extensive experience in the language, but that doesn’t mean I made it just for the sake of it! The code is admittedly rough, having been put together over a weekend—it’s more of a Minimum Viable Product than anything else. Version 2.0 will be a more professional implementation with a much cleaner codebase. If you’d like to check out or use Riscrithm v1.1 (which has many more useful features), I highly recommend visiting the repository!
Riscrithm is an intuitive RISC-V assembler designed to make writing assembly simpler. Its syntax is meant to be clean while staying strictly aligned with native machine instructions. The GitHub repository offers a detailed description of Riscrithm v1.0.0, along with a Developer Manual in the README.md for an deep dive into its syntax (the README.md also includes a short summary of what v1.1.0 will include). While v1.0.0 isn’t perfect, work is underway on version 1.1.0, which will add important new features to the language. The compiler is written in Go, with versions available for Windows, Linux, and Apple (both AMD64 and ARM64). For any further questions, feel free to leave a comment on the post.
I've been thinking along somewhat similar lines of a C but instead of a PDP 11 as the virtual machine, why not risc V.
Could of questions.
Do variables as registers get enforced at all? If you're going to have any type of function you need to that the first arg goes in the right place.
Second. One risc V instruction doesn't necessarily mean one risc V instruction. So I don't think you should be holding yourself to the same standard. This then makes while loops possible and easier to read if statements.
For me the benefit of something like this is knowing what is happening under the hood. I don't need to know that a statement will translate to one instruction, just that I understand what instructions it will actually expand to.