今天写一个简短的小话题，内容很少，今天猜一回riscv isa里面定义时一个小点。猜测存在不完全和因果关系错误的概率，但去猜测一下不是挺有趣～（评论区更有趣， 有浇CPU的冷水， 还有撒RV图灵完备+dsa扩展的热水）
要聊的这个点就是：
riscv的integer instruction set并没有定义“乘累加”指令，为什么没有定义？
F/D扩展指令是定义了FMA指令的。
V扩展，也是定义了“乘加指令”。V扩展指令集，要把乘累加相关指令在架构上考虑。如果是发生在占比概率低的指令没有被基础指令集定义，是容易理解的。乘累加，应该是V扩展使用概率高的指令。
那么是忘记在integer scalar指令集里定义了吗？ 必然不是。
分析一下对于integer unit，如果定义整数乘加指令，会在微架构设计时，带来那些改变。
目前可以打败或者pk一下intel和amd的CPU微架构是什么？ 对的，是苹果的M1 CPU微架构，和arm的V/X系列的CPU微架构。 那么M1和X系列的CPU微架构设计中的定位是什么？
是“kilo instruction processor”，可以接近 “一千条指令量级的 OoO windows”去寻求“推测执行”的微架构。当然对于这样子的CPU比如高要求带宽和延时的memory系统和互联，也是更难的，今天不讨论这部分。话说回来，要做到如此高并行度的推测能力的微架构，是“微架构”，“低访存延时”和“工程实现，工艺”很多因素一起作用。
但是，猜测一下，在riscv isa定义的时候，是否做一些折中，而让“实现超宽CPU”的一个部件的设计时，相对变得比之前的容易一点，即使设计时做了每条指令3个源操作数有效，对于integer指令部分来讲，第3个操作数寄存器实际有效的概率很低。
要实现这个接近千条指令规模的OoO windows，要宽的 decoder 和 rename。同时，不能让pipeline太长，pipeline越长，对于这个“kilo”大家伙的错误penalty就越大， 因为大，所以错的多，错的长（latency）也会导致错误多。
目前amd商用公布zen最大的dispatch uops能力是8。 arm的x4的每周期的dispatch 最多10 mops或最多20 uops， arm是如何做到每个周期最多10条指令同时完成寄存器重命名的？每条指令有3个源操作数寄存器，那就是30个源操作数寄存器，在一个stage内读寄存器映射表。当然3个源寄存器操作数有效的，概率是很低的。虽然概率低，但是硬件是现实，依旧要考虑的。微架构设计时是要满足全部条件的。可以满足dispatch 10 mops的场景，应该是不多的，可能10个指令里面有一半是只有1个源操作数寄存器有效。
这里arm肯定是在寄存器重命名的前一个stage，完成一些必要的计算，比如每个指令依赖关系，三个源操作数是valid和invalid，同时再细化“合理的利用寄存器重命名表的读和写“。
讲回来，riscv为这里布局了吗？为以后的高性能的扩展是不是可能做点折中。
猜测一下，
只有乘加指令是三个源操作数的指令，如果riscv的scalar integer计算指令不定义乘加指令，会让integer unit的使用”乘“和”加“两条指令完成等同操作，相对比会是降低。可能对于integer unit的性能，乘加指令的被使用的概率和微架构实现是目标折中，只是一个大胆的猜测。
但是，如果设计一个”kilo OoO windows“的riscv cpu，8-width decoder，对于integer unit的所有指令最多只有2个源操作数，来设计微架构时寄存器重命名时，实现上更好一些。
也许这就是riscv在架构定义阶段，考虑微架构实现上难度，做了架构定义的结合了integer unit性能，vector unit性能与微架构实现的折中。
如果猜测是对的话，那么”riscv isa是懂微架构的“，对吧。
虽然riscv在integer isa里没有定义乘加指令，如果真的是为了更宽实现容易实现。那是合理的理由，依旧保持指令集完备性，这也就是一种“合理”。
