Login
You're viewing the f.duriansoftware.com public feed.
  • Aug 15, 2026, 5:44 PM

    Interesting (if a bit sweary) critique of #RISCV . Quoting from the very end of it:
    "Before you get your megaphone to shout about "openness", please note that the openness of the RISC-V spec is not relevant here at all, because an open spec does not magically materialize a well-designed out-of-order core for you for free. And if someone were to design a good out-of-order core, they would not be giving it away for free."
    dmitry.gr/?r=06.%20Thoughts&pr

    💬 2🔄 2⭐ 0

Replies

  • Aug 15, 2026, 6:16 PM

    @csepp that was fun!

    although sadly, it seems i have to revise my opinion of RISC-V. it's a less boring architecture than i had imagined... in the worst possible way. at least ARM (even ARMv6-M) has aspects you can point to and go "ooh, that looks fun! i can think of exactly three things where that is exactly the instruction you'd need". MIPS is just straight-ahead dull. but RISC-V's departures from boring all seem to tend towards painful

    💬 1🔄 1⭐ 0
  • 💬 0🔄 0⭐ 0
  • Aug 20, 2026, 4:29 AM

    @spycrab @csepp i was already aware of the lack of any decent addressing modes (though i wasn't aware that an optional extension has implemented literally half of a fix for that). i was dimly aware that anything more than the absolute minimal set of useful instructions was in optional extensions. profiles always looked painful and like an attempt to fix the problems of extensions. i knew about the haphazard encoding (although arguably it doesn't make any difference in hardware; it's just a pain for people writing emulators).

    i didn't know that they had reused the same encoding for two radically different instructions - that's a rookie mistake - but i was aware that since compressed and uncompressed instructions can be freely mixed, jumping into the middle of an uncompressed instruction was likely to end up executing a very different compressed equivalent, which is a bit of a gift to retpoliners and a bus crash waiting to happen for everyone else. i didn't know that non-word-length loads and stores were even more restricted in addressing mode than word-length ones. i pretty much read the article with mounting dismay.

    and in particular, for a device that seems destined to live and die in microcontrollers, interrupt handling seems woefully inept, especially compared with the ARM Cortex example. sure, you don't have to stick with the C ABI conventions, but only by not using C (or an ABI-compatible language); but who wants to program the damn thing in assembly language?

    💬 0🔄 0⭐ 0
  • Aug 15, 2026, 7:09 PM

    @csepp On the other hand, the #RiscV specification is about 500 pages, whereas the #ARM one is FIFTEEN THOUSAND PAGES. I'll put up with a lot for not having even to prune out the parts of that mountain that I don't think I'll need to read.

    💬 0🔄 0⭐ 0
  • Aug 15, 2026, 8:36 PM

    @darkling @csepp The ARM spec is extensively documented with examples and even code you can use in a simulator to prove correctness. The RISCV spec is an amateurish document full of ambiguity, and their frequent response to clarifying this is “look at the sailfish implementation and do that”

    💬 0🔄 0⭐ 0