undefined | Better HN

0 pointsadrian_b2y ago0 comments

This kind of implementation (with the computations done locally in the memory or memory controller or cache controller) has already been proposed and implemented in 1981, in the NYU Ultracomputer project, i.e. the first time when such fetch-and-operation instructions have been proposed as a superior alternative to the swap or test-and-set instructions that had been previously used to ensure mutual exclusion in multiprocessor systems.

So this RISC-V extension, while very useful and actually mandatory for any CPU with a high core count, has nothing original or new, but it just follows a 40-years old established practice.

From the point of view of the memory, these atomic operations are always read-modify-write cycles. Whether the data travels up to a CPU core or only on a shorter path, depends on the implementation, but this does not change the meaning of the operation.

0 comments

brucehoult2y ago

> [...] RISC-V [...] has nothing original or new, but it just follows a 40-years old established practice.

That is a very precise description of RISC-V as a whole.

RISC-V very deliberately does not try to break new ground technically, but consolidates the best of not only the 40 years of RISC history (and avoiding the things that turned out to be outright mistakes, or just not necessary), but even you could say the last 60 years with ideas taken from enduring designs such as IBM System/360 and Cray-1.

Being able to prove that every feature in RISC-V is either so old and so common as to be unpatentable, or else that it was patented and the patent has expired, is an essential part of RISC-V's protection against the Intel/AMD and Arm duopoly (and others). As is every company that joins RISC-V International certifying as part of joining that they do not have any IP claims against the ISA.

> while very useful and actually mandatory for any CPU with a high core count

And yet somehow A53 and A57 didn't have it!!!

The very first RISC-V chips for public sale -- the FE310 in December 2016, and the FU540 in early 2018 -- both have the AMO instructions. The former despite being a single core microcontroller with only SRAM and no external memory bus, where CLI/SEI will do the job.

sylware2y ago

For instance, I heard hhe ISA does avoid the mistake of the FLAGS everywhere which is supposed to be a nightmare for out-of-order processors.

brucehoult2y ago

Right. The only high performance clean sheet ISA designed since 1990 with FLAGS/condition codes is Aarch64. Alpha: no. Itanium: no. RISC-V: no.

You could perhaps argue that Aarch64 was not quite entirely clean-sheet, as for the first decade or so virtually all Aarch64 implementations had to share registers and pipelines with ARMv7.

The "since 1990" limit is the RS/6000 (aka POWER aka PowerPC), which understood that FLAGS are a bottleneck in superscalar designs, and tried to solve this by having 8 complete sets of flags instead of the usual 1. So in a way it's a step on the path from FLAGS to no FLAGS too.

By far the most common case in code is to do some kind of comparison and then immediately branch on the result of that comparison. RISC-V integrates this into a single "compare and branch" instruction. The surviving ISAs that use FLAGS now fuse the conditional branch instruction with the preceding instruction that sets the FLAGS.

In the much rarer case where you want to do a comparison and branch based on it only some time later, modern ISAs allow you to save the result of the comparison into any of the general-purpose integer registers, using either `slt`, `sltu` or simply `sub`.

j / k navigate · click thread line to collapse

0 pointsadrian_b2y ago0 comments

So this RISC-V extension, while very useful and actually mandatory for any CPU with a high core count, has nothing original or new, but it just follows a 40-years old established practice.

0 comments

brucehoult2y ago

> [...] RISC-V [...] has nothing original or new, but it just follows a 40-years old established practice.

That is a very precise description of RISC-V as a whole.

> while very useful and actually mandatory for any CPU with a high core count

And yet somehow A53 and A57 didn't have it!!!

sylware2y ago

For instance, I heard hhe ISA does avoid the mistake of the FLAGS everywhere which is supposed to be a nightmare for out-of-order processors.

brucehoult2y ago

Right. The only high performance clean sheet ISA designed since 1990 with FLAGS/condition codes is Aarch64. Alpha: no. Itanium: no. RISC-V: no.

You could perhaps argue that Aarch64 was not quite entirely clean-sheet, as for the first decade or so virtually all Aarch64 implementations had to share registers and pipelines with ARMv7.

j / k navigate · click thread line to collapse