if ConditionPassed() then
    EncodingSpecificOperations();
    if SInt(R[m]) == 0 then
        if IntegerZeroDivideTrappingEnabled() then
            GenerateIntegerZeroDivide();
        else
            result = 0;
    else
        result = RoundTowardsZero(SInt(R[n]) / SInt(R[m]));
    R[d] = result<31:0>;

So for A64 recent gcc compilers compile that fragment to:

f:
        cbz     w1, .L6
        clz     w1, w1
        sdiv    w0, w0, w1
        ret
.L6:
        brk #1000

Whilst gcc 6 does the divide-by-zero via a conditional select:

f:
        clz     w2, w1
        cmp     w1, 0
        csel    w1, w2, w1, ne
        sdiv    w0, w0, w1
        ret

x86-64 is similar to A64 but using a branch rather than a conditional select in gcc 6.

Finally, if you are curious, clang simply assumes it doesn’t need to worry about the undefined case (which it doesn’t, it is undefined) and removes the zero check entirely. That means it ends up dividing by whatever the clz (or equivalent) instruction returns on 0 (which varies depending on instruction set).

So…

If we hand the following C to the GNU C compiler (including the RISCstar toolchain) then it will generate breakpoint instructions (or “undefined” instructions on x86-64):

int f(int x, int y) {
    return x / (y ? __builtin_clz(y) : 0);
}

The ternary would normally be an inline function but has been fully expanded in the example above. It has been defensively coded to avoid calling __builtin_clz(0) (which is undefined). Sadly in our case the output is used as a divisor meaning that, although the ternary has a defined value, there is still a divide-by-zero if y is zero… and that is also undefined.

Compilers can do pretty much anything when there is undefined behaviour (including removing the zero check entirely) but gcc’s behaviour is interesting. It recognises there is no point in generating any real code to implement behaviour that is known to be undefined so it generates a breakpoint instead!

f:
        beq     a1,zero,.L7  # Branch to .L7 if argument 1 is zero
        clzw    a1,a1        # Count Leading Zeros in Word 
        divw    a0,a0,a1     # Divide Word
        ret
.L7:
        ebreak               # Breakpoint

Doing a little archaeology led me to discover that gcc has been doing this since gcc 7.1 was released in 2017. However I’ve never seen it before. Perhaps I just don’t write enough undefined behavior bugs!

Anyhow, if you actually do find this is interesting, this is the Compiler Explorer sandpit I used to examine things a little more:

There is actually a “secret” here (so don’t tell anyone ). The RVA23U64 binaries are actually built for rv64gcv_zicond_zba_zbb_zbs. This is not quite as aggressive as RVA23 and there is real hardware that can run the binaries today.

To be extremely clear this was a convenience for testing rather than some clever plan. The default build settings will change once real RVA23 hardware becomes available so don’t expect to be able to run later versions of the RISCstar toolchain on non-RVA23 hardware. That’s why it’s not documented and will remain so.

Again however, its absolutely fine to take advantage of this information for tasks like benchmarking.

Others are very welcome to disagree but I personally think RVA23 marks such an important shift in the ecosystem that it’s better to baseline on this than to have needlessly slow compilers when RVA23 hardware arrives. As you observed we ship a couple of older versions of the toolchain where the native builds target RV64GC. That is offered just in case people with pre-RVA23 hardware really need them for comparative benchmarking and so on..

Finally, just in case there is any doubt, the toolchain itself can build binaries for whatever profile you want. The bundled libraries for the Linux toolchains are built for RV64GC but, in most cases, you’ll be dynamically linking anyway so the libraries you get at runtime are whatever comes from the distro you are running on the target board.

The toolchain is based around gcc 15.2 supported by binutils 2.45 and gdb 16.3. Depending on the toolchain edition you will also find linux 6.5 kernel headers, glibc 2.38, musl 1.2.5 and/or newlib 4.5.

Note that 15.2-r1 is the first release where the RISC-V hosted compilers require RVA23. Learn more about the RISCstar toolchain at the RISCstar blog.

New topics can only be created by the admins.

Feel free to discuss new extensions and other exciting things that are added to the architecture.

This is the forum recommended (and linked to) from the RISCstar toolchain web page. It is a community discussion forum so feel free to share your experience and expertise.

RISCstar community forums

Join us to talk about Arm, RISC-V and embedded Linux

Here are some things you can do to get started:

Introduce yourself by adding your picture and information about yourself and your interests to your profile. What is one thing you’d like to be asked about?

Get to know the community by browsing discussions that are already happening here. When you find a post interesting, informative, or entertaining, use the to show your appreciation or support!

Contribute by commenting, sharing your own perspective, asking questions, or offering feedback in the discussion. Before replying or starting new topics, please review the Community Guidelines.

If you need help or have a suggestion, feel free to ask in Site Feedback or contact the admins.