camel-cdr

Their original slides had Ascalon silicon in 2024 at 3ish GHz, now the devboard is supposed to be next year at 1.38GHz on an older node and it still has not taped out yet as of last month.

SiFive only supports it in their new generation performance cores.

So you basically get a full AVX-512/SVE level SIMD ISA, minus FP support and with 64-bit SIMD width. But you still have LMUL, which will be great here to maximize utilization.

How much of a thing is this in practice? To me this also feels driven by the expectations of the host towards the guests beeing fully accommodated by them. It's probably a mixture of both.

Like, I'm happy to bring my own food, when invited. E.g. I would presume most vegans would be cool with bringing their own or ordering, as you are used to that anyways.

Zba would probably give a small boost. Zbb gives a substantial boost to perf for applications that use clz/popc heavily, but I don't think that would apply to python.

On concern I have is how this maps to ARM64 syntax, because ARM64 is massively overloading all mnemonics.

For example:

    ld1d z0.h, p0/z, [x1, x2, lsl 3]
    ld1d z0.h, p0/z, [x1, z0.h, lsl 3]

    ld1d dst, p0/z, [base + idx<<3]

Also, maybe I missed it, but how are you dealing with things like the /z modifier, pre/post-increment load/store and load pair? Or things like TBL/ST4/LD4?

Oh and how are the types going to work for RVV, where the type can't be determined at compile-time in all situations?

Most ISAs do.

On x86 and arm scalar and FP registers are separate, it's just that they overlap FP and SIMD registers.

On RISC-V there are three separate register files for scalar, FP and SIMD. Although you can overlap scalar and FP in some minimal embedded configurations.

When I had brief access to a very early P870 devboard running at 2GHz it scored 2% worse than an 2.86GHz Cortex-X1 in the 7-zip benchmark compression (it was a 40% worse in decompression, but that has NEON optimized Arm assembly path and non for RISC-V). Because this was very early hardware still in bringup I expect them to get closer to the announced 2.7GHz.

But yeah, the RISC-V geekbench scores of publically available RISC-V processors are suprizingly low and idk why. Part of it is the lack of RVV support is certain workloads, but that doesn't explain the entire gap. When I looked at ST scalar performance my self it looked more comparible to similarly sized Arm CPUs.

I think I'll have to order a Pi5 (Cortex-A76) and investigate where it performes different to the SpacemiT K3 (SpacemiT X100).

On paper they should be very similar, both 2.4GHz, 4-wide decode, 3xALU, 1xBranch, (although the A76 has those on 4 execution units, while the X100 has 3 with one sharing ALU and Branch support), 2x load/store, 2xFP. The biggest obvious difference (appart from ISA), may be the cache setup after L1, with the K3 having a 4Mib L2 shared between 8 cores (no L3) and the Pi5 having a 512KiB L2 and a 2MB L3 shared between 8 cores.

I'll have to try out the branch.

* Tenstorrent Ascalon has a neat optimization for certain LMUL>1 SIMD operations. LMUL=2 effectively unrolls the SIMD operation making it read two SIMD registers from every source and write two SIMD registers to the destination. There are however some instructions where LMUL=2 only needs to write to one registers, those are narrowing instructions (e.g. 64-bit to 32-bit truncation) and comparisons (which write to a LMUL=1 register with packed bits). When those SIMD instructions have to .vx form, which means one argument comes from a GPR, they now only need to write one SIMD register and need to read two SIMD registers. This matches what regular SIMD instructions need and because the silicon for the execution is much cheaper than register file ports, Ascalon can exexute these instructions in a single operation. So you can compare twice as many SIMD elements against a scalar, then you can against another SIMD register.

* Ventana (now under Qualcomm) talked a tiny bit about their fetch-block-optimizer and something that sounded like a L1i-trace cache. The fetch-block-optimizer would go to certain hot L1i entries and "optimize" them, with agressive instruction fusion including fusion of non-adjacent instructions.

* NextSilicon: Idk any details yet, but they said they handled RVC without increasing latency and that they've found a good solution for implement RVV and especially LMUL, which is a challange in out-of-order designs.

* OpenXiangShan: The fastes open-source CPU, is working on doing 2-ahead instruction fetch (the thing Zen5 added).

Now that being said, Ventana was bought by Qualcomm, we know the RISC-V team is still alive, but who knows if we'll ever see anything from that outside of Qualcomm?

The Tenstorrent Ascalon devboard is way behind schedule and on 12nm TSMC instead of a 4nm node the processor was designed for and is now supposed to clock at 1.38GHz. Though I think the delay has more to do with TT management problems then with the actual design.

While the scalar part of OpenXiangShan looks really good, the RVV imolementation is currently basically unusable. They want to have fix for the problems until the end of the year, but we'll have to see.

> In an Armv9.0 implementation, if FEAT_FP and FEAT_AdvSIMD are implemented, the following features are implemented: ...

This implies they don't have to be implemented.

https://support.arm.com/documentation/109697/2026_06/Feature...

> FEAT_FP is OPTIONAL from Armv8.0.

> FEAT_AdvSIMD is OPTIONAL from Armv8.0.

But also:

> All Armv8-A systems that support standard operating systems with rich application environments also provide hardware support for Advanced SIMD instructions.

and

> All Armv8-A systems that support standard operating systems with rich application environments provide hardware support for Advanced SIMD and floating-point instructions. All Armv9-A systems that support standard operating systems with rich application environments also provide hardware support for SVE2 instructions. It is a requirement of the ARM Procedure Call Standard for AArch64, see Procedure Call Standard for the Arm 64-bit Architecture

So, both FEAT_FP and FEAT_AdvSIMD are optional for Armv9-A and Armv8-A.

But both are mandated in cores for "rich operating systems", which basically means it's mandated by the OS.

Also, Armv9-A on OS level mandates SVE2.

    total: 15510
    #0:  3720
    #31: 2247
    #1:  1349
    #21: 1208
    #2:  810
    #3:  524
    #8:  493
    ...