4 ms·

That is solving a completely different problem. The RISC-V AMO instructions are designed and intended to be implemented such that the arithmetic part is NOT ex

That is solving a completely different problem. The RISC-V AMO instructions are designed and intended to be implemented such that the arithmetic part is NOT executed in the CPU in a read-modify-write sequence -- only very low end CPUs (microcontrollers, that don't have a real memory hierarchy or multiple processors anyway) do it that way. What actually happens is this: amoadd.w rd,rs2,(rs1) All of rs1 (the memory address), rs2 (the amount to be added), and a field indicating this is an AMOADD, not AMOMIN, AMOXOR etc or even a plain store are send out on in parallel fields on the peripheral bus (e.g. TileLink-C or TileLink-UH) until it gets to either the actual endpoint containing the target address (perhaps an I/O device and register), or the point where the target address is found to be accessed by a simple read/write (TileLink-UL) bus -- this is often the last-level cache controller. But it could also be an L1 or L2 cache for another CPU core, or in another CPU cluster, or even in a completely different computer with the addr/data/op triple passing over 400G ethernet or NVMe or something on the way. In either case, this point is much closer to the data than the originating CPU is. The TileLink device at that point atomically reads the memory contents, performs the arithmetic, stores the new value, and then sends the old value back to the CPU just the same as for a memory read. From the CPU's point of view, the AMO is just like a memory read, except extra data (the value to be swapped, aded, xored etc) is sent with the address ... so that's like a write. AMO instructions do not add any new complexity or state sequencing to the CPU core, compared to simple load/store. I use TileLink as the example bus, as it was co-developed with RISC-V at Berkeley, but may RISC-V CPU cores can use AXI (or both), and Arm has recently added similar capability to AXI.

adrian_b 3y ago
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.
- brucehoult 3y 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.
  - sylware 3y 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.
    - brucehoult 3y 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`.

adrian_b 3y ago

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.

brucehoult 3y 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.
- sylware 3y 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.
  - brucehoult 3y 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`.