The existing a64 conditional branch instructions use a 19 bit field to hold the offset. Add two registers to compare (10 bits) and 3 bits to choose between EQ, NE, LT, LTU, GE, GEU and you're already at 32 bits before having an "opcode" field to choose "RISC-V style conditional branch".

Of course you could reduce the branch offset size down to RISC-V's ±4k which only needs 11 bits when you only have 4 byte instructions, but that's still a 24 bit chunk of unused opcode space to find.

Oh .. looks like 0b10xx is still completely unused. We could grab maybe 1/4 of it

So could do ...

    [31:28] (4 bits):  0b1000 (Fixed primary opcode .. or 0b1001, 0b1010, 0b1011)
    [27:23] (5 bits):  Rs1
    [22:18] (5 bits):  Rs2
    [17:15] (3 bits):  Cond (EQ, NE, LT, GE, LTU, GEU, + possible 2 more)
    [14:4]  (11 bits): Offset (Signed ±4k PC-relative offset)
    [3:0]   (4 bits):  0b0000 (Fixed minor opcode/extension identifier)

Maybe...

    [31:28] (4 bits): 0b1000 (Fixed primary opcode)
    [27:21] (7 bits): Offset[12:6]
    [20:16] (5 bits): Rm
    [15:13] (3 bits): Cond (EQ, NE, LT, GE, LTU, GEU, etc)
    [12:10] (3 bits): Offset[5:3]
    [9:5]   (5 bits): Rn
    [4:2]   (3 bits): Offset[2:0]
    [1]     (1 bit):  sf (Size flag: 0 = 32-bit compare, 1 = 64-bit compare)
    [0]     (1 bit):  0b0 (Fixed)

Some ::coff:: would criticise the split up offset field. Not RISC-V fans of course. And this puts sf in a non-standard place.

Some more playing around is needed .. over to you Arm.

Interestingly Synopsys's ARC's latest version ARC-V is RISC-V.

I think all major FPGA vendors now offer fully supported RISC-V soft cores either alongside their older proprietary ISAs or as the latest upgrade. Several (e.g. Microchip and Gowin) have included real RISC-V cores inside FPGAs.

Just like Debian still runs on original x86-64-v1 from 1999, not x86-64-v3 (needs AVX2,FMA, BMI1, BMI2, LZCNT) or even x86-64-v3 (needs AVX-512).

Similarly, Debian for arm64 still requires only ARMv8.0-A from 2011 not even ARMv8.2-A (everything from A75/A55 to A78/N1/V1) let alone ARMv9-A (A710, A510, X2 and on).

Why would they do in the RISC-V world what they totally haven't done in amd64 or arm64?

I could of course be wrong but I think the publicly known history sets the pattern pretty reliably for the speculation.

There is still plenty of unused 32 bit (30 bit) opcode space.

> I assembly by hand almost any function that is not too simple I can make it shorter on Cortex-M33 than on RISC-V

Not if you use the RISC-V ISA properly.

If they did everything exactly the same they would be the same ISA not different ISAs.

It's just as easy to point to things that RVC can do that T16 can't.

You need to look at a far larger picture to decide on who made the better decisions overall.

They did that with x86 and Arm half a decade before any announcement about a switch, not to mention a number of other ISAs that didn't make it to shipping (e.g. M88k) and probably ones that word has never leaked about. IA64, anyone?

They're too large and rich and risk-averse to *not* do it.

I'm with Jim Keller when he says that in time the fastest CPUs will be RISC-V ones.

YESSSS.

I've been pointing this out for years and years.

By the point that you're looking at the same propagation delay as a common 64 bit adder you're decoding 64 chunks of 16 bits per cycle. That's 128 bytes, or a 32-64 instructions wide decoder.

That is so much wider than anyone is making or contemplating — or that even makes sense given the size of basic blocks — that it's just a non-issue.

Debian has no plans to require more than RV64GC.

RVA23 is a very good thing in certain markets, but nothing forces you to support it for a personal project.

Intel has being fusing `CMP` and `Bcc` since Core 2 and AMD since Zen 1.

This is

- already one instruction in RISC-V

- an *extremely* common pattern, often occurring once every 5 or 6 instructions.

But *code size* is a demonstrable fact.

RISC-V has by far the most compact code of any popular 64 bit ISA, and that was true even of RV64GC. The gap has only widened with RVA23.

Just load up your favourite OS (e.g. Ubuntu 26.04) for various ISAs in Docker and compare the `text` size of various binaries, individually or in aggregate.

In 32 bit ARMv7-M / ARMv7-A had a small code size lead over RV32IMAC, but this is reversed in modern RISC-V e.g. if you look at RISC-V Hazard3 vs Arm Cortex-M33 in the RP2350 (Raspberry Pi Pico 2) where you can trivially change one option setting in your project and recompile and test.

The only exception is that the M33 has a single-precision FPU, which neither the Hazard3 nor the Cortex-M0+ in the RP2040 have.

- Dylan

- Scheme

It helped immensely that both Gwydion Dylan and Chicken Scheme compile their respective niche languages to portable C code.

Now emitting LLVM IR is an even slightly better technique. Except for PA-RISC. So GCC 15 (or HEAD) and C generation it is ... it's not bad using modern headers with portability defines such as `uint32_t`, ability to return at least a pair of values in registers, or tail calls using all argument registers if you convert to CPS (as e.g. Chicken does)