alt Hacker NewsAll Intel, AMD or Arm-based CPUs and any other modern CPUs have dozens of errata, even if some CPU vendors keep them secret, instead of publishing them, as they should.
Fortunately, most of the erroneous behaviors are triggered only by very unlikely combinations of circumstances, some of which may even be impossible to happen in user programs, but only in operating system kernels.
Nevertheless, from time to time there are also serious errata, like the one discussed here, which can be triggered even by ordinary user programs. Sometimes, like here, such errata can be avoided by compilers patched to not generate the buggy instructions for the affected CPU models, assuming that it is known with certainty on which model of computer the compiled program will be executed (or using code dispatch at run time, based on the CPU model).
Simplicity in the CPU hardware may reduce the probability of hardware bugs, but it increases the probability of software bugs, because the missing hardware features must be implemented at a much greater cost in software, like in the case with the missing integer overflow detection of RISC-V, which causes most RISC-V programs to omit overflow checks, increasing the chances of undetected bugs.
Replies
And Rust omits overflow check under the same excuse, although overflow was a reason that allowed multiple Linux kernel vulnerabilities.
> Simplicity in the CPU hardware may reduce the probability of hardware bugs, but it increases the probability of software bugs, because the missing hardware features must be implemented at a much greater cost in software, like in the case with the missing integer overflow detection of RISC-V, which causes most RISC-V programs to omit overflow checks, increasing the chances of undetected bugs.
Since I've got a SpacemiT K3 board my self now, I though I test it again:
I compiled microjs with both tinycc and chibicc, which where both compiled for the target platform with and without -ftrapv:
Last time I did full clang: https://news.ycombinator.com/item?id=47328214#47342362 And there was minimal slowdown (sometimes speedup) on x86, Arm and RISC-V. It was pointed out that llvm mostly uses size_t, however chibicc and tinycc use int as their default type, so there should be lots of overflow checking.