[rwmj]

Aarch64 dropped thumb instructions.

I don't think you're going to find a single benchmark on the effectiveness of compressed instructions since it really depends deeply on both the workload and the whole system. For example, memory bandwidth and cache pressure are both important for whether smaller text sizes matter, and that may depend on what else is running at the same time.

Note your assembler may be automatically compressing instructions without you asking. You'll have to disassemble the binary to find out.

[camel-cdr]

You can benchmark stuff with and without RVC. Once there is faster hardware I want to do such a comparison with a full gentoo build for both sides.

However, quantifying what the result will actually mean is nearly impossible, because you don't know what the hardware cost was.

[sylware]

Maybe the best approach is to remove C from RVA while keeping it around in the specs for niche applications where text size _really_ matters (with current silicon processes, I wonder how weird those niche applications have to be to require C). But it seems some would remove C even from the specs to free some ISA space. If arm removed thumb...

Don't worry, I would know if the assembler is producing C machine instructions, my rv64 interpreter on x86_64 does not support the C instructions at all.

[brucehoult]

You can't remove C from future RVA because a large part of the value of RVA is that each version can run all the shrink-wrapped (binary distribution) code built for the previous versions.

[sylware]

Well, I said that because based on the documents provided here, it seems there are key people considering its removal even from the specs.

From my point of view, just do like all the others: clearly deprecate it, namely say that "from RVAx, don't create new machine code with the C extension". It is like in the linux kernel, it will then be removed very far in the future. But RISC-V is all about the far future, it can only be better to fix it asap.

After reading the comments and documents provided here, I am the first to be suprised by how much doing 'performant C' is not that easy and has a significant hardware cost. "arm removing thumb" should have been a strong signal.

Again, I am coding rv64 assembly almost every day, a good part could be C-ized to shrink text size, but based on various numbers provided here, why bother, better keep the 'R' of RISC as faithfull to its goal than anything else.

[brucehoult]

> "arm removing thumb" should have been a strong signal.

I don't see any reason to think that Arm ISA designers are any more skilled and knowledgable than RISC-V ISA designers. Given the relative number of people and the amount of academic and industry expertise you'd rather expect the opposite! Retired Arm ISA designers such as Dave Jaggar who designed Thumb and Thumb2 are on record as saying that the RISC-V designers have done a fine job, and that RISC0V is the current state of the art.

When I tested my Primes benchmark on a Pi 4, the variable-length Thumb 2 version was the fastest as well as, of course, the smallest.

    11.190 sec Pi4 Cortex A72 @ 1.5 GHz T32          232 bytes  16.8 billion clocks
    12.115 sec Pi4 Cortex A72 @ 1.5 GHz A64          300 bytes  18.2 billion clocks
    12.605 sec Pi4 Cortex A72 @ 1.5 GHz A32          300 bytes  18.9 billion clocks

[sylware]

But on the overall, based of the documents and information provided here, and what I think I managed to understand about them: it is not surprising some want to start the deprecation of C from RVA (some would even start its deprecation from the core specs to free some machine instruction encoding space).

It is a bit like compilers: 90% of the complexity/size is for 30% of the code optimization speed gain, which has mostly a significant and pertinent impact in specific work loads on our modern hardware. Basically it is "better" (since you get rid of 90% of the complexity/size of compilers) to combine pure assembly coding with less complex/bigger compilers ("10%") (and look at dav[12]d, not to mention ffmpeg, here the main issue is feature creep of ISO C new things and GCC extensions... and abuse of the nasm pre-preprocessor). For instance, with bzip2, with cproc/qbe (zero assembly though), I get 70% of the speed of modern gcc/clang. But what's really worrying: I talked (I think it was here on HN a long time ago) to one of TheHeavyThing assembly coders, and he said that with a brutal and naive hand-compilation of the corresponding C code, he got 15-20% faster than the best compiler could provide at the time on gzip compression. Something is up here, and I already did mention dav[1]d and ffmpeg.

We are in a 101 case of 'compromise', and here, it seems the more I read about it the more I think we are facing a case of 'benefits are not worth it in the end', well the apparent 'competent' people who are in the sauce seems to agree more and more about it, through the infos I have been getting from HN.

As for the 'compilation' benchmarks provided here, we know gcc/clang are heavily x86-64 oriented, namely goes into optimizations which should favor 'C' like machine instructions (destination register same than some source register), so the 1-2% "real" speed increase from some documents provided here sounds more like the real neutral/overall thing to me.