首先来个黑历史，8个月前对LA664的预估：

然后是目前爆料出来的规模：6发射乱序执行，4个定点单元，4个浮点单元，4个访存单元，ROB256项。
我只能说我还是太保守了，或者我还是太小看了龙芯，你看这脸打得，啪啪的响……

继续，先预测一下LA664。
取指应该还是从GS464E沿用下来的32B，对应8条指令，对于6发射来说足够了，问题是LA664支持SMT，那要如何为2个线程分配取指带宽，牙膏厂的方案是每周期交替，农企的方案是拆成2个16B每个线程各占1个，两家采用不同方案的原因主要是X86指令长度不定，需要在解码前增加一个预解码的阶段，以确定指令的边界，农企在指令载入缓存的同时对该缓存行进行预解码，并将预解码信息存储在缓存TAG中，取指说是2组16B，其实是2组2个指令且2个指令长度不能超过16B。而牙膏厂预解码是在指令队列中进行的，取指的时候还不知道指令边界，只能一股脑的将16B缓存都先取进指令队列。对于指令等长的LA来说，情况更类似农企，只不过不需要通过读取缓存TAG就能分辨指令边界，并且也不需要考虑指令超长的问题，所以LA664采用2组16B设计的可能性更大一些。

指令队列，这个逻辑部件在GS464E中，同时还承担了循环缓冲的功能。如果需要保留此功能，指令队列估计还是需要每个线程独占一个，以免线程A的指令流对线程B的循环体造成干扰。规模上沿用GS464E的64项，差不多也能涵盖程序中的大多数热点循环，实在要增加应该不会大于96项吧。农企的推土机是32项，后面增加到40项，ZEN是借用了op cache，牙膏厂在2个线程公用和独占之间反复横跳，直到Skylake之后就都是2个线程独占，Ice Lake是2组70项。

分支预测，GS464E采用的是分支目标缓冲+动态分支预测器+返回地址堆栈+间接目标缓冲的组合，涵盖了非条件分支，条件分支，调用返回，间接分支几乎所有分支指令类型。LA464应该沿用了这款组合，但规模可能比GS464E要更大一些。
具体分开来分析，GS464E的分支目标缓冲规模非常小，LA664应该会增大，但不知道会不会引入目前高端核心常见的多级BTB。
GS464E的动态分支预测器采用的是本地/全局复合预测器，本地应该是双模预测器，全局应该是按地址分set的两级自适应预测器，这套设计和推土机非常的类似，但推土机也证明了本地/全局复合预测器并不适用与多线程的环境，在多线程模式下，推土机的全局两级自适应预测器被2个线程互相干扰，几乎无法发挥正常的作用。牙膏厂在SNB重新引入SMT后，为避免线程间干扰，配备了2套动态分支预测器，分别为2个线程所使用，当然这个方案非常蠢，浪费了面积和功耗，所以在Haswell就换成了变种的TAGE。农企在ZEN上使用的是所谓的神经网络预测器，其在分类上属于本地预测器，所以并不受多线程影响，但预热非常的慢，到了ZEN2，为了解决神经网络预测器的问题，在其后又加一套TAGE，后来农企也发现这么做非常的蠢，到了ZEN3去掉了神经网络预测器，直接使用TAGE。这两家在面对SMT对分支预测造成的影响时，兜兜转转最后殊途同归，都采用了TAGE或者类TAGE的分支预测器。龙芯在上SMT时应该会参考这两家的教训，估计LA664会直接一步到位采用TAGE作为动态分支预测器。
返回地址堆栈没什么好讲的，加规模就是了。间接目标缓冲，记得龙芯之前讲到过，二进制翻译缺少对间接跳转的支持，估计龙芯会类似具有二级地址翻译的TLB一样，搞出个具备二级地址预测的间接目标缓冲，具体怎么搞我也不知道，只不过理论上TLB能X86虚地址-LA虚地址-实地址这么映射，间接目标缓冲应该也能这么映射，大不了翻译模式下损失一半的容量，总比没有要强，兆芯你说是不是。

解码器是最没什么好说的，RISC指令等长，最多3输入和1输出，LA还没有eflag指令，除了可能存在极少数需要解码成多条微操作的指令外，应该都能做到指令与微操作一对一解码，这比X86要简单太多了，所以6个解码器应该都是对称设计。但因为LA操作码变长的原因，还是要比RV要复杂一些，可能和ARM差不多，一个操作码变长，一个有eflag指令。

之后就是寄存器重命名阶段了，在这里会通过一个映射表，实现指令集架构与微架构的寄存器之间的解耦，可以更好的利用微架构那数量远多于指令集架构的寄存器，消除因程序编译时寄存器重名产生的指令之间伪写后读和写后写相关，以便更多的指令能在下一阶段实现乱序执行。LA464已经是采用物理寄存器，在寄存器重命名阶段，将之前解码好的微操作按功能区域进行处理和分割。首先为src1、src2、src3、dest（可能还包含imm，如果需要包含imm，则在此阶段还需要将imm中的数据存入重命名后的寄存器中）分别分配空闲的物理寄存器编号，并将映射关系按指令顺序存入ROB，ROB中存储的是原始指令的寄存器编号和重命名后的物理寄存器编号，其结构为：“原寄存器1编号”+“原寄存器1映射的物理寄存器编号”+“原寄存器2编号”+“原寄存器2映射的物理寄存器编号”+“原寄存器3编号”+“原寄存器3映射的物理寄存器编号”+“原目标寄存器编号”+“原目标寄存器映射的物理寄存器编号”+其他控制位，长度估计在62-66bit（LA464 2组128项寄存器62bit应该够了，LA664大于2组128项寄存器，每组映射各加1bit，预计需要66bit）。而微操作中的src1、src2、src3、dest则被替换成映射后的物理寄存器编号后，继续送往下一阶段来到调度器，或者也叫保留站。如果是非物理寄存器的设计，在寄存器重命名阶段，ROB中存入的是原始指令的寄存器编号和其中的数据，如果目前数据尚未载入，则先保留长度置为全零，其ROB的结构就变为：“原寄存器1编号”+“原寄存器1需存储的数据”+“原寄存器2编号”+“原寄存器2需存储的数据”+“原寄存器3编号”+“原寄存器3需存储的数据”+“原目标寄存器编号”+“原目标寄存器需存储的数据”+其他控制位，如果考虑到需要与向量寄存器通用，当向量宽度为128bit时，其长度为542bit，而当向量宽度增加到256bit时，其长度会达到1054bit。当然还有一种给向量指令分配多项ROB的方式，但这反过来又会导致ROB的实际可用数量减少。所以在支持向量指令的微架构中，采用非物理寄存器的设计，反而会导致复杂度的增加，而大量的数据移动也会增加延迟和功耗，导致频率提升困难。农企在推土机及其之后就一直采用物理寄存器设计，而牙膏厂在NetBurst已经采用了物理寄存器设计，但在Core2和Nehalem反而退回到了非物理寄存器，但在SNB及其之后又重新采用物理寄存器设计，兆芯就可能奇特了，根据chipsandcheese那篇文章，以赛亚已经采用了物理寄存器的设计，但兆芯“改进”成五道口的时候，又变成非物理寄存器的设计了，而下一代的CNS又是物理寄存器设计。

调度器中每一项的结构和微操作基本类似，但为了实现tomasulo算法，会增加一些控制位，以提示数据源寄存器是否已经载入数据，当所有数据源均已就位，且所需的执行管线空闲时，该条微操作就会发射到执行管线中。执行管线根据微操作中src的物理寄存器编号读取数据源，并根据op设置执行方式和选择输出结果，然后结果按照dest的物理寄存器编号存储到指定的物理寄存器中，之后根据物理寄存器编号找到ROB中对应的条目，将其控制位中的表示已写回的更新为1。在该条目移动到队列顶端时，如果已写回的标志位为1，就能执行提交阶段，根据该条目存储的物理寄存器编号与逻辑寄存器编号的映射关系，将对应物理寄存器中的数据，提交给程序可见的逻辑寄存器，并将该条目从ROB中删除，同时ROB中后续所有条目均前移一项，至此完成提交。在微操作发射到执行管线后，如果src所对应的物理寄存器编号，不存在与调度器内的其他微操作中，则需要及时将其释放，以便后续微操作寄存器重名时使用。
由上可知，ROB、物理寄存器、调度器三者之间的数量关系。1.ROB只要未提交，均需占用1项物理寄存器，用于映射目标寄存器；2.调度器只要未发射，均需占用1-3项物理寄存器，用于映射源寄存器；3.部分微操作的源寄存器相同，或者其源寄存器为其他微操作的目标寄存器；4.可流水微操作的最大延迟周期数*管线数量+调度器的项数，应小于等于ROB的数量（否则可能出现因没有足够的ROB，在即便调度器存在空闲的情况下，依旧无法派发微操作从而导致流水线气泡产生的情况，虽然反过来也会产生气泡，但毕竟调度器是无序队列，结构比有序队列的ROB要复杂很多，更不应该让复杂结构被简单结构所限制）。现在已知LA664的ROB为256项，如果假设可流水微操作的最大延迟周期数为5，执行管线数量为12，则调度器合计项数应小于等于196项。如果假设整数和浮点物理寄存器各256项，合计512项，则调度器应该大于128项（因为平均所需的源寄存器数量会少于2）。考虑到LA664的调度器应该还是会沿用GS464E以来，分成整数、访存、浮点向量三个的设计，如果进一步假设这三者的项数相同，并且考虑到执行管线的数量可能会是4的倍数，则在合计128-196项的范围内有44、48、52、56、60、64项这几种可能。个人偏向于48项，整数、访存、浮点三者合计144项，相比LA464增加50%。

在浑浑噩噩之中讲完了和乱序执行相关的几个逻辑单元，回过头才发现，这哪是在畅想，这根本是在上课，也难怪没人讨论了，小小的反省一下，后面尽量少讲原理多瞎猜，反正都是扯淡
书接上回，接下来就是执行管线了。目前已知的信息表示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%。

接着是缓存系统，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保持静态分配。