[benj111]

This looks interesting.

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.

[patrick-ghetea]

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!

[brucehoult]

> 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.

[benj111]

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.

[patrick-ghetea]

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!

[benj111]

>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

[patrick-ghetea]

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.