在浑浑噩噩之中讲完了和乱序执行相关的几个逻辑单元，回过头才发现，这哪是在畅想，这根本是在上课，也难怪没人讨论了，小小的反省一下，后面尽量少讲原理多瞎猜，反正都是扯淡
书接上回，接下来就是执行管线了。目前已知的信息表示LA664可能存在整数管线、访存管线、浮点向量管线各4条，正好是6发射的2倍，非常合理且优雅，我本能的选择相信。
其中4条整数管线应该继承自LA464，但是否是龙芯之前传统的对称设计就无法确定了。根据之前龙芯介绍二进制翻译进展情况的某个视频中，提到某些二进制翻译加速指令只能在某条管线上执行，导致翻译效率无法继续提高。而根据老的LoongISA二进制翻译加速指令，推测具有继承关系的LA二进制翻译加速指令中，除了少数处理X87模式的指令以外，其他大多数应该都是整数指令。所以可能LA464的整数管线中只有1条可以执行二进制翻译加速指令，这也侧面证明了LA464的整数管线并不是类似GS464E的对称设计。当然也不排除是二进制翻译加速指令中的浮点部分只能跑在指定的浮点管线上，毕竟之前龙芯的人曾提出过开启软浮点提升二进制反应的兼容性的方案。不管如何，我LA664的面积还要小于LA464，所以我猜测LA664的整数管线极大的概率会采用非对称设计。具体的分配上，考虑到为同时多线程提供足够的执行单元，应该会以2条为1组，4条形成2组，2组之间对称设计。每组内有1条只能执行所有延迟为1个周期的整数指令，另1条能执行除分支以外的所有整数指令。这样相当于每周期最多4个加或2个乘+2个分支，高延迟的乘除法计算并不会对分支指令造成因结构相关所引起的流水线冲突，使分支指令可以尽早发射执行。结合独立于ROB的BRQ，可在分支指令执行完成时实现分支预测错误后对流水线的精准刷新，使分支指令的提前发射执行具有减少性能损失的意义。而二进制翻译指令中的整数部分，基本都是与设置EFLAGS寄存器相关的，并不需要复杂的运算，但却有按照EFLAGS寄存器的值进行循环或跳转这种分支指令，所以如果不是4条整数执行管线都可以执行的话，应该会和有分支单元的在同一条执行管线中。

连整数管线都是非对称设计了，浮点向量管线这种占面积巨大的东西，肯定也是非对称设计了。估计和整数管线一样，也采用2条为1组，4条形成2组，2组之间对称的设计。每组内2条都能执行逻辑、加、减、乘、乘加、乘减等基本浮点或向量运算，但其中只有1条能执行除、开方、倒数、指数、对数等复杂浮点或向量运算，另1条能执行比较、转换、分支等其他浮点或向量运算。因为二进制翻译指令中的浮点部分，包括了X87的浮点格式与标准格式之间的转换指令，所以应该也会在具有其他浮点单元的执行管线中。
最后是访存管线，4条访存管线实在是太吓人了，感觉龙芯是真的在认认真真的在解决他们研究发现的问题（胡老师多次提到茶壶里倒饺子，虽然编译后的指令中40%都是访存指令，但个人理解只要设计合理，其并不是主要性能瓶颈，至少不是在寄存器与缓存之间，也许是我的理解还没有达到那个水平吧）。猜测访存管线同样采用分组对称组内非对称的设计，2条为1组，每组内2条均能执行载入，但只有1条能执行存储，整体实现每周期4载入或3载入1存储或2载入2存储的性能。访存队列在LA464已经实现的载入和存储的分离设计，但规模对比ZEN和SKYLAKE还是小了一些，所以我猜测LA664会在继承分离设计的访存队列的同时，进一步加大规模，例如达到96项载入队列+64项存储队列，也就是相比LA464各提升50%和33%。

厉害，学习到了

顶

接着水LA364啊

接着是缓存系统，GS464E以来，龙芯的大核都采用了差不多的缓存结构。64KB 4way L1I+64KB 4way L1D，对于64B的缓存行来说，64KB的容量意味则缓存行数量为1024项，4way的话就是每路256项。L2为256KB 16way，计算下来也是每路256项，且L2为L1I和L1D的牺牲缓存，内容互斥，相同的每路项数，意味着TAG结构相同，在做缓存替换的时候，可以减少换算所需的硬件和延迟，非常的巧妙，所以LA664在这部分应该也不会改变。L3估计会比3A5000的16MB少一半，桌面环境很少有能发挥16M大缓存的场景，况且龙芯桌面CPU与服务器CPU在3A5000时代开始使用不同的版图，也没必要为了服务器的应用环境，同样为桌面CPU配备大缓存，造成桌面CPU成本和功耗的提升。所以3A6000的L3估计会回归到3A4000的4核共享4bank，每bank 2MB，合计8MB。同样14nm工艺节点，桌面和服务器分开设计的skylake，其桌面版本也是4核共享8MB L3。作为相对3A5000 L3容量减半的补偿，相连路数可能会从16way增加为32way。根据我的理解，在组相连的缓存中，相连路数越多，某特定缓存行被替换出缓存的概率越低，但缓存整体的访问延迟越高。所以L3容量减半路数翻倍后，在大多数应用环境中，整体的缓存命中率应该相差不大，访问延迟略微增加，但L3作为末级缓存，其延迟对性能的影响并不像L1那样明显，所以这样的设计还是具有性价比的。

然后是快表缓冲，也就是TLB。根据指令集手册，在TLB的管理维护上，LA沿用了MIPS和大部分RISC常用的软件方案。也就是当发生类似TLB失效这类需要对TLB进行操作的时候，会产生一个例外从用户态退到核心态，然后交由操作系统专门的程序来完成对TLB的操作。LA设计了一系列专门的指令，用于加速对TLB的操作，即便如此，这些操作依旧需要处理器切换上下文并占用流水线来执行。虽然龙芯早在MIPS时代就设计了2个专用的寄存器，减少了对通用寄存器进行保存所需的时间，但例外产生后对流水线的刷新，依旧会导致ROB中指令的取消，而这些指令很可能已经通过乱序完成执行了。所以，和分支预测错误类似，TLB失效出现的频次越高，性能的损失就越大，并且ROB越大、流水线越长，性能损失也越大。相对的，在硬件管理维护TLB的方案中，需要额外的硬件对TLB进行操作。当发生TLB失效时，类似缓存失效，流水线暂停，等待专用硬件完成TLB操作，之后继续启动流水线，期间并不会产生上下文切换，也不会刷新流水线。总结下来就是在TLB失效时，软件管理造成的影响类似分支预测失败，硬件管理造成的影响类似缓存未命中。当然这只是类比，毕竟无论软件管理还是硬件管理，造成的损失中都需要包含访存延迟，但一般软件管理会比硬件管理的延迟高出至少和流水线级数相当的周期数，所以大多数采用软件管理的RISC的流水线级数都不会太高，这对频率的提存在不小的影响。设计需要考虑整体，各部分必须互相妥协，所以之前一直有宽的微架构频率做不高的说法，在我看来，其本质至少包含了又宽又深的微架构在TLB重填上的性能损失过大没有存在的意义这点。今天的主角是LA664，目前有消息说其采用和LA464相同或同代的制程能跑到3GHz，但LA664比LA464规模要大很多，如果不是LA464的设计存在问题，那就是LA664采用了很多针对高频的设计。其中拉长流水线就非常直接的一种，例如LA464 12级的流水线在重新划分后达到了15级，那即便采用同的制程，其频率也会从2.5GHz提升到3.1GHz。LA464的12级流水线为：PC、取指、预译码、译码I、译码II、寄存器重命名、调度、发射、读寄存器、执行、提交I、提交II，和GS464E的一样，那哪几个阶段可以拆分呢？个人觉得，首先预译码应该可以拆成2个阶段，甚至3个阶段。预译码阶段主要是做分支预测，GS464E的动态分支预测器是本地/全局复合分支预测器，而GS464V/LA464采用的是COTTAGE，TAGE有个特点就是预测延迟比较高，毕竟它比之前的两级自适应结构要多的多。农企在ZEN2首次使用TAGE时，为了隐藏TAGE的延迟，将TAGE作为神经网络预测器的纠正器来使用，神经网络预测器虽然预热时间长，但延迟低，ZEN2流水线中首先会根据神经网络预测器的判断进行后续的取指，仅当后续TAGE的判断与其不一致时，再取消后按TAGE的判断重新取指，这样大多数情况下分支预测的延迟等于神经网络预测器的延迟，剩余少数情况下等于TAGE的延迟，平均下来相当于减少了TAGE的延迟。当然农企的这些骚操作在这里并不重要，关键是TAGE的延迟高到农企舍得为其再花费一个神经网络预测器的晶体管。回过头看LA464，在分支预测阶段和之前的GS464E一样依旧只占一级，也就是说LA464的COTTAGE需要在一个周期内产生预测结果，而这“一个周期”在流水线其他任何阶段都是等长的，这就导致COTTAGE的延迟决定了LA464“一个周期”的长度，如果COTTAGE的延迟无法继续减少，频率就无法继续提升，频率的倒数等于COTTAGE的延迟。所以在LA664上，如果可以将COTTAGE的延迟拆解到2个甚至3个周期中，那至少频率不会被这个高延迟的逻辑单元所限制。其次是读寄存器应该也需要拆成2个阶段，目前LA464的整数寄存器是128项，应该有12个读口+7个写口，前面假设LA664应该会增加到256项，规模增加了100%，延迟肯定要增加，这还不算完，LA664还增加了2条访存管线，浮点部分整数浮点转换的管线也会增加1条，整数寄存器的读写口也会跟着增加到至少16+10。这么大的规模，这么多的读写口，这访问周期肯定也很大，如果这个阶段不进行拆分，也会成为影响频率提升的一个地方。总体下来LA664的流水线级数估计会是14-15级左右，相同制程频率应该能提升15%左右。说了这么多，再回到TLB的问题上，更长的流水线虽然提供了更高频率的可能，但也为TLB软件管理带来了更高的延迟，而LA664更宽的设计也会带来更多的性能损失，这一切都与高其IPC设计相违背。解决的方案有两种，一种是更新LA指令集，允许处理器采用硬件管理，操作系统做配套的修改，但可能会造成兼容性问题。另一种是在软件管理的皮之下包着一个硬件管理的心，LA664依旧设计有操作系统可见的STLB和MTLB，由软件管理，容量甚至可以不考虑访问延迟设置的非常大，然后在靠近L1I和L1D处分别设计了ITLB和DTLB，这2个TLB操作系统不可见，容量也考虑了延迟做的比较小，由专门的硬件管理。当ITLB或DTLB未命中时，先暂停流水线但不触发例外，然后访问STLB和MTLB，如果STLB或MTLB中存在该TLB条目，则将其载入ITLB或DTLB，之后流水线继续，如果STLB和MTLB也未命中，再发起例外，上下文切换交由操作系统完成TLB的重填，然后载入ITLB或DTLB，最后上下文切换回原来的进程。这相当于利用了局部性原理，在保持绝大部分TLB访问延迟的前提上，增加了软件维护的TLB的容量，减少了TLB例外的概率，让采用TLB软件管理对又长又宽的流水线的影响降到最小，扫除了龙芯未来继续做更大更快微架构的掣肘，同时还保留了软件的兼容性。

水了这么多也不知道有没有人看……互联拓扑、IO、封装这些准备放到LA364里已经写了，接下来准备猜LA364了。
LA664基本猜完，总结一下就是：32B取指、COTTAGE分支预测器、2组各64项循环缓冲、6路解码器、256项整数寄存器、256项浮点寄存器、48项整数调度器、48项访存调度器、48项浮点调度器、256项重排序缓冲、64项分支队列、96项载入队列、64项存储队列、整数管线：ALU/MUL/DIV+ALU/BRU+ALU/MUL/DIV+ALU/BRU、访存管线：LOAD+LOAD/STORE+LOAD+LOAD/STORE、浮点管线：FMA/FCVT+FMA/FDIV+FMA/FCVT+FMA/FDIV、向量单元宽度256bit、64KB 4way L1I、64KB 4way L1D、256KB 16way L2、8MB 32way 共享L3、128项 全相联 ITLB、128项 全相联 DTLB、128项 全相联 MTLB、4096项 16way STLB。

楼主有空就不要停 追更中

楼主，拜年之余，可以继续水了。

同步多线程还是单独发一层吧。
手上牙膏厂的资料比较少，先以农企为例吧。ZEN系列的SMT通过三种方式对硬件资源进行分配：竞争、水印、静态。竞争是指按需分配，只要还有空闲资源，任意线程都可占用，某个线程甚至可以完全占满所有资源；水印是指虽然是按需分配，但每个线程存在占用的上限，此时即便整个硬件单元仍有空闲资源，但依旧无法给该线程继续分配资源；静态是指将硬件单元静态的分成2半，分别给两个线程使用，每个线程只能使用自己所属那一半的资源。处理器具有2个线程模式，农企将其分别成为T1和T2，在运行的某个时间点，只能处于某个线程模式。这三种分配方式中，由于竞争可以将所有资源都分配给某个线程，所以不存在线程模式切换。而水印和静态由于需要切换线程模式，在切换前需对采用这两种分配方式的硬件单元进行刷新，所以每次切换都会产生大量流水线气泡，导致性能损失，农企在手册上也提到应尽可能避免频繁的进行线程模式切换。到具体的产品上，ZEN/ZEN2的微码ROM、派发单元、整数调度器、整数和浮点寄存器、载入队列、各级缓存（包括微操作缓存）和各级页表缓冲都是按竞争方式分配，浮点调度器和内存访问缓冲是按水印的方式分配，微操作队列、存储队列、ROB是按静态的方式分配，剩下未提到的硬件单元，不是物理上就配备了2份各自独占，就是采用了FMT的方式分时共享。到了ZEN3，整数调度器、整数寄存器、载入队列从竞争修改成水印方式。而牙膏厂这边，Netburst的分配方式要简单的多，除了部分单元采用了双倍资源或FMT以外，剩下的主要队列和物理寄存器，都采用了类似静态的分配方式。
龙芯这边有关同时多线程的文章目前能搜索到的有3篇，分别是2005年的《龙芯2号多线程扩展的研究与设计》、2006年的《龙芯2号处理器多线程技术研究》、2009年的《龙芯2号处理器的同时多线程设计》。这3篇内容都大同小异，第一篇的作者是XX超，第二篇的作者是XX松，但在第三篇中我们看到署名中有许先超和李祖松，之前那两篇的作者应该就是这两位，所以基本可以将第三篇看做是相关研究继续发展完善后的“定稿”，当然LA664的SMT和第三篇中的带多线程设计的龙芯2号肯定是不一样的，但相关技术肯定在那时就开始积累沉淀了，就例如农企除了推土机系列以外的微架构总是带着21264的影子，所以我们还是可以管中窥豹可见一斑。文中也设计了2个线程模式：超标量模式和多线程模式，对应农企的T1和T2。在多线程模式中，除了农企和牙膏厂都有的分时共享、竞争分配和静态分配以外，也存在类似农企水印的一种共享方式——动态分配但不能全占。由于受到当时能力的限制，寄存器重命名映射表和物理寄存器文件只能按两个线程各一份独占的方式进行了设计，但是分时共享上突破了简单机械的FMT，做到了可以根据队列负载选择性的分时共享。整理下来，这个支持同步多线程的龙芯2号中，各级缓存竞争共享、TLB静态分配、取指窗口根据2个指令队列的负载分时共享、指令队列独占、分支预测单元中的BTB和PHT竞争共享、BHR和RAS独占（这个设计类似SNB）、解码器根据2个指令队列的负载分时共享、重命名映射表独占、物理寄存器独占、调度器按最低保留4项动态分配、分支队列独占、访存队列静态分配、ROB静态分配。14年后的现在，LA664在此基础上，预计各级缓存保持竞争共享，各级TLB中硬件维护的ITLB和DTLB可以竞争共享，软件维护的STLB和MTLB保持静态分配，取指窗口保持根据负载分时共享，指令队列保持独占，分支预测单元因为采用了COTTAGE，除了RAS是独占，其他都是竞争共享，解码器保持根据负载分时共享，现在龙芯的技术应该可以将重命名映射表升级成动态分配了，同样物理寄存器也升级成动态分配，调度器保持动态分配，同样也因为COTTAGE的存在，分支队列有可能会变更为静态分配，访存队列保持静态分配、ROB保持静态分配。

好了终于到LA364了，我就怕更得太慢，还没预测完，结果龙芯的手册都出了，好在现在龙芯的手册里都不带微架构介绍了
预测LA664时主要参考了LA464/GS464V和GS464E，LA364则需在LA664这个预测的基础上参考GS264/LA264，而GS264/LA264的资料非常少，并且LA364除了一个3发射几乎没有任何参数爆料，另外就是一个IPC 9分的成绩，比同为3发射的K10高了0.5分，所以在规模上也参考了K10，其他我就放飞自我的猜了，当然猜错的可能性也就更大了。
首先根据LA364整体上的应用场景，应该没有高频的设计要求，所以10级左右的流水线应该就可以了：取指、预译码、译码、重命名、调度、发射、读寄存器、执行、提交I、提交II。
取指宽度16B，也就是每周期4个指令。
指令队列12项，去除了GS464E/GS464V/LA464上指令队列同时作为循环缓冲的设计，LA364的指令队列仅仅是取指与解码之间级间寄存器的放大版，为了隐藏中间预译码阶段分支预测的延迟。
对于流水线较短的LA364来说，即便简化分支预测单元，对整体性能的影响可能也很小，但节省的面积和功能却不少，所以我猜测LA364的分支预测单元可能会比较小。BTB为256项4way；动态分支预测器采用gshare，因为gshare在各种动态分支预测器中具有最佳的能耗延迟积，也就是说gshare更适合低成本低功耗的微架构，GHR长度14bit，截取分支指令PC的低8bit，然后GHR在低位、PC在高位，重叠的6bit进行哈希，拼接后形成16bit的索引，PHT为16K项，按索引中纯来源与PC的高2bit分成4个bank；JBTAC为1024项；RAS为32项。这个规模整体上比GS464E略小，和K10差不多，BTB小了很多，但龙芯的BTB都很小所以我也不敢猜很大，动态分支预测器规模上一致，但采用了更先进的gshare，剩下的JBTAC和RAS略大于K10，保持整体上面积相当。
解码器3路，这个没什么好写的。
调度器应该还是龙芯经典的整数+访存+浮点，3组分体式的设计，3者分别32项，和LA464一致，相比K10的3*8+42=66项，整体大了不少，但浮点小了23%，也就是说更注重整数通用性能。
物理寄存器，整数128项+浮点向量128项，和LA464一致，但浮点物理寄存器每项的宽度为128bit，是LA464的一半。
执行管线，LA664的猜测中，执行管线采用了分组对称的设计，取其1组就正好是LA364的执行管线，整数ALU/MUL/DVI+ALU/BRU，访存LOAD+LOAD/STORE，浮点向量FMA/FCVT+FMA/FDVI，其中访存和浮点向量的宽度为128bit。相比LA464，整数管线减少了一半，相比K10整数管线减少了33%，虽然浮点管线数量上也减少了33%，但执行单元上多出了一套FADD和FMUL。结合调度器的规模，与K10相比，LA364整数的乱序队列更深但执行资源更少，浮点则正好倒回来，乱序队列更浅但执行资源更多。我这么猜测主要是因为LA的整数指令普遍具有相对X86更低的执行延迟，指令在管线中逗留的时间更少，同样的面积用来提升乱序队列能比增加管线数量获得更大的性能提升，而浮点则是因为低延迟设计的浮点单元面积非常大，更多的执行单元可能在相似的性能下比低延迟的执行单元面积还小一些，这一切都是为了面积。
重排序缓冲128项，也和LA464一致，相比K10的72项，大了77%。
分支队列32项，重排序缓冲的1/4，和LA464一致。
载入队列48项，存储队列32项，规模在LA464和K10之间。
缓存系统，L1I为64KB 4way，L1D为64KB 4way，和LA464一致，比LA264大了一倍，但去掉了LA464上作为L2的牺牲缓存，LA464上共享式的L3成为LA364的L2，但为了更低的访问延迟，可能会采用16way甚至8way的设计，每个核心对应1个bank，每个bank 1MB，所以双核的2K2000 2MB L3，八核的2K3000 8MB L3。
页表缓冲，同样采用了LA664的硬件管理+软件管理，ITLB 64项 全相联，DTLB 64项 全相联，MTLB 64项 全相联、STLB 2048项 16way或8way。
整体上LA364采用了相比LA464更小的前段、略少的执行管线、类似规模的乱序队列、简化的缓存系统，达到了LA464 85%的IPC。硬件上大量复用LA464或LA664对称2组中的1组，以达到模块化设计快速出货的要求。

写的很精彩，我比较关注3a6000看来到3ghz还是有可能的啊