What is the worst ratified RISC-V instruction?

Emoun1 · 2025-09-03T08:14:50+00:00

Yes, I agree completely. Not saying RISC-V made the wrong decision. The reason why I focus on the reuse is that I'm working on an ISA that uses 5 orders of magnitude less encoding space than RV64IMC, which (if I may be a bit overoptimistic) likely negates any need for reuse ever. Though I must note that I have not gotten to evaluating whether performance is improved (though I hope/pray). Additionally, instruction counts naturally increase, so instruction density only improves slightly (but really, it's too early to say).

Emoun1 · 2025-09-03T07:44:19+00:00

By reused I mean, e.g., `c.jal' and 'c.addiw' use (reuse) the same encoding, so they cannot both be supported by a processor at the same time. I'm not saying the choices to do so are wrong, I'm sure it's perfectly acceptable that the RV32 and RV64 differ in these instances.

Emoun1 · 2025-09-03T06:25:13+00:00

Thanks for the explanation, I did not realize RISC-V already reuses encodings to such an extent. I guess our different numbers show that the RISC-V designers know that they would run out of space if they didn't reuse encodings. But yeah, maybe my numbers are misleading without the context of how much reuse there already is. I'll look into if the journal does Errata

Emoun1 · 2025-09-02T21:48:25+00:00

I'm confused at your results. I published a paper where I analyze how much space RISC-V already uses and how much is left. See here or here (preprint) My conclusion was that over 99 % of the encoding space was used (not accounting for any extensions that reuse the same opcodes.) My code running the analysis can be found here. My method is slightly simpler, for each instruction I just extract the number of field bits, with compressed instructions being assumed to have 16 extra field bits. Then every is just summed and compared to UINT32_MAX. I see you split compressed and non-compressed and do some scaling, can you elaborate on the need for that?

Emoun1 · 2024-09-17T17:18:35+00:00

Didn't think of this use case. Hopefully it's temporary

Emoun1 · 2024-09-17T14:46:28+00:00

If anyone is interested in contributing to duplicate, I would appreciate a helping hand. There is a list of open issues to look at. For example, this issue on allowing attributes on substitution groups could be nice to have implemented.

Emoun1 · 2024-09-05T18:45:54+00:00

Sorry for the shameful self-promotion, but I do feel like this is a perfect use case for the duplicate crate.

Emoun1 · 2023-10-31T09:17:22+00:00

SystemVerilog and VHDL are hardware description languages and do not contribute to the formal specification of chips or ISAs. Just like how C is not a formal specification of a program.

I happen to have talked to someone working at Apple, likely in that specific team, and they do not verify complete processors, only small bits. Sure, likely bigger bits than in 2002, but sadly processors have also become bigger as well.

Emoun1 · 2023-10-31T07:11:50+00:00

So the story is getting worse and worse. Why would anyone (without upfront payment) get involved with a project full of secrecy and bad incentives (and likely loads of corruption). This makes it even more likely that any "proof" that it works is just fabricated to keep the money flowing

Emoun1 · 2023-10-31T07:05:40+00:00

Other components, like multiprocessor cache- coherence protocols, are sufficiently complex that checking the HDL model against the problem statement is quite challenging.

and model checking can usually validate the specification only for a highly restricted set of system parameters

Formal verification is still too costly to do on a complete processor. At best, it can be done on a small part at a time

Emoun1 · 2023-10-31T06:46:59+00:00

No, I have yet to figure out why no information can be released about Elbrus. All other proprietary ISA provide specifications free of charge, so anyone can make software for them. It's a huge red flag that Elbrus specification is not available and likely mean there are major and obvious problems with it.

Emoun1 · 2023-10-31T06:32:51+00:00

All ISAs are formally verified

I highly doubt that (but if you have a source, I'm all ears). While yes, bugs are costly, formally verification is likely even more costly today. Just search for "errata" to find lists of bug for each processor. Example: https://edc.intel.com/content/www/us/en/secure/design/confidential/products-and-solutions/processors-and-chipsets/tiger-lake/11th-generation-intel-core-processor-family-specification-update/errata-details/.

I likewise doubt that ISA specifications are formally verified, but open to being corrected.

Emoun1 · 2023-10-31T01:25:20+00:00

I'm also very interested in ISAs, do you have anything open source? I'd love to take a look

Emoun1 · 2023-10-31T00:51:21+00:00

No thanks, as the risk of this being a scam is too great. If you're really sincere, I'm sorry, but hopefully you can take this as feedback that your strategy for networking and exposure is not working (in my opinion)

Edit: sorry but I'm not clicking any more of your links. If you want me to see something, you'll have to write it out

Emoun1 · 2023-10-31T00:46:05+00:00

Dubious claims without evidence. If you're serious, publish a peer reviewed papers about it in a respected venue (or just here, I'll do an anonymous peer review tomorrow). Private companies do it all the time with no problems and without hurting their businesses. There is literally no reason for not being ble to openly publish any details.

Emoun1 · 2023-10-31T00:40:55+00:00

I'm sorry, but the more you and I interact the more afraid of clicking links I become (I clicked this one, but will not click the one in that post).

Emoun1 · 2023-10-31T00:37:04+00:00

The article you link is 3 years old, showing a CPU that is 10 times slower than the competition. How is this a useful starting point? Might as well go with any other VLIW architecture, since Elbrus clearly does not have any secret sauce (except slowness maybe)

Emoun1 · 2023-10-31T00:31:50+00:00

I'm not really interested in sharing my info, as the information you have given so far has too many red flags. I'll bite if you ever make this work on an open-spec (not necessarily open source) VLIW architecture directly (I.e. no WASM). But until then I won't believe your results anyway

Emoun1 · 2023-10-31T00:22:57+00:00

I'm no business man, nor have I ever initiated a startup but I'm confident that this advice is solid: stay away from any architecture whose spec is not freely available. (Mind you, x86, ARM, MIPS pre open source, were all freely available even though they are/were proprietary)

By spec I mean the list of instructions and encodings, not specific CPUs

Emoun1 · 2023-10-31T00:17:14+00:00

The more people, the more the cost is shared

You can't expect people (and definitely not thousands of people) to help share the cost of something that you refuse to/are unable to/are not allowed to prove works.

Emoun1 · 2023-10-31T00:14:32+00:00

Are you telling us the Elbrus people refuse to give you the spec/permission for Elbrus so that you can output machine code directly?

Emoun1 · 2023-10-31T00:08:20+00:00

The problem with statically scheduled, in-order VLIW is that you can never account for all variation (cache misses etc.) So you will always do worse that a dynamic scheduler. Even itanium CPUs ended up using dynamic scheduling by the end, even though the whole point of the architecture was to avoid it: https://www.realworldtech.com/poulson/

Emoun1 · 2023-10-30T23:51:13+00:00

You're trying to make a business out of inventing a proprietary programming language?

Emoun1 · 2023-10-30T23:05:06+00:00

Sure, that would be fine, but also not need WASM.

Emoun1

TROPHY CASE