> Yes, as I said. Not at the point I was composing my reply. > If fusion of load/store instructions is indeed an important part of the RISC-V design I don't

> Yes, as I said. Not at the point I was composing my reply. > If fusion of load/store instructions is indeed an important part of the RISC-V design I don't believe that it is. Certainly no RISC-V implementations that are in the hands of customers right now do any fusion and it doesn't seem to hurt their ability to match or exceed the performance of similar Arm cores (A55, A72). I have heard that some of the companies making very high performance cores (Apple M or AMD Zen class) are incorporating some fusion. Perhaps they will provide compiler patches if required. > I think that it would pose a problem for compilers that generally assume symmetry (addressing modes supported by loads are assumed to be supported by stores too). I think they would manage. There is certainly precedent e.g. MSP430 has 4 addressing modes for src operands but only 2 for dst (register, register indirect with 16 bit offset). Plus of course every ISA where its an addressing mode not a different instruction allows "immediate" on a load but not on a store. > i.e. a fused instruction does not do the same thing as a corresponding architectural instruction, as the fused instruction has more side effects That can never happen. Fusion will simply not be done in that case. > but if the integer ISA was designed with support for three source operands from the start, it would be an even better fit for those segments And I don't think the difference would be enough to measure or care about — single digit percentage on number of clock cycles needed. And meanwhile the simpler core may allow at least the same percentage to be gained as higher clock speed, or more cores on a die, or other compensating factors.