MIPS的演化 MIPS16是一個1997年面世的可選的指令集擴展，它能減少二進制程序尺寸的30-40%。實現者希望這種CPU能夠在很關心代碼尺寸的場合中更有吸引力--這種場合通常就是指低成本系統。由於只應用於特定實現，它是一個多廠商標准：LSI, NEC和Philips都生產支持MIPS16的CPU。 使MIPS二進制代碼比其他架構的並不是MIPS指令集干的活少了, 而是他們的尺寸更大一些--每個指令4字節長，相比之下某些CISC架構一般平均只有3個字節。 MIPS增加了一種模式，在這種模式下CPU可以對16位固定大小的指令進行解碼。大多數MIPS16指令擴展成正常的MIPS III指令，所以很明顯這將是一個相當受限制的指令子集。竅門就在於使這個子集對足夠多的程序充分的進行高效編碼，以使整個程序的大小得到大大的壓縮。 當然，16位指令並不會使其變成一個16位指令集。MIPS16 CPU是實際存在的帶有32位或者64位寄存器的的CPU，MIPS16 CPU的運算也都在這些寄存器上。 MIPS16遠不是一個完整的指令集—例如它既沒有CPU控制指令，也沒有浮點運算指令。但沒有關系，因為每一個MIPS16 CPU也必須要運行完整的MIPS ISA。你能運行MIPS16和正常的MIPS代碼的混合指令。每個函數調用或者跳轉-寄存器指令都能改變運行模式。 1．並不是MIPS發明了提供一種可選的使部分指令只有一半大小的創意。Advanced RISC Machine（ARM）公司的Thumb版本的ARM CPU首先提出這個想法的。 在MIPS16中把指令地址編碼成最低有效位(Least Significant Bit, LSB)模式是既方便又高效的。MIPS16指令必須偶字節對齊，所以bit 0不再是指令指針(instrUCtion pointer, 就是程序計數器PC)的組成部分了；取而代之的是，每條跳到奇數地址的指令開始執行MIPS16，每條跳到偶數地址的指令回到正常的MIPS。MIPS子程序調用指令jal的目標地址總是字對齊的，所以新指令jalx隱藏了指令的模式間轉換。 為了把指令壓縮到一半大小，對於大多數指令我們只分配了3 bit來選擇寄存器，這樣只有8個通用寄存器允許自由訪問；在許多MIPS指令中可以見到的16 bit常數域也被壓縮，通常變成了5 bit。許多MIPS16指令只指明兩個寄存器，而不是三個。另外，還有一些特別的編碼規則將在下一節描述。 D.1.1 MIPS16中的特殊編碼格式和指令 被縮減的通用指令沒有什麼問題，但有兩個特定的弱點會加大程序尺寸；5 bit的立即數域構造常量是不夠的，在load/store操作中也沒有足夠的地址范圍。三種新的指令和一種特別規定有助於解決這些問題。 extend是一條特殊的MIPS16指令，它由5 bit的代碼和11 bit的域構成。這個11 bit的域可以和後續指令中的立即數域相連接，這樣就允許使用一個指令對來對16 bit立即數編碼。這條指令在匯編語言中看起來就像一個指令前綴。 裝載(load)常量在正常的MIPS模式下都需要額外的指令，在MIPS16模式下更是巨大的負擔；把常量放在內存中然後再讀它們會更快一些。MIPS16對相對於指令自身位置的裝載操作(PC-relative loads， PC相關裝載)增加了支持，允許常量被嵌到代碼段中(典型情況就是在函數的起始處前面)。這些是僅有的不是嚴格對應於正常的MIPS指令的MIPS16指令—MIPS沒有PC相關的數據操作。 許多MIPS load/store操作是直接在棧幀(stack frame)裡，$29/mp可能是最普通的基寄存器。MIPS16定義了一組隱式使用mp的指令，允許我們把函數的棧幀引用地址也編進去而不需要一個分離的寄存器域。 MIPS的Load指令總是生成32位的全地址。由於裝載字(load Word)指令只有當地址是4的倍數是才合法，最低兩位就被浪費了。MIPS16的Load指令是可以伸縮的：地址的偏移量會根據被load/store的對象的大小左移，這樣就增加了指令中可用的地址范圍。 作為一種額外的應急機制，MIPS16定義了一些指令，允許在8個MIPS16可訪問的的寄存器中的一個與32個MIPS通用寄存器中的任何一個間任意做數據移動。 D.1.2 對MIPS16的評價 MIPS16對於匯編語言編程來說不是一種合適的語言，我們也不准備對它詳細說明。這些是編譯器的工作。大多數使用MIPS16模式編譯的程序的尺寸都會縮小到用MIPS模式編譯的 60-70%。MIPS16比32位CISC架構的代碼更緊湊，和ARM的Thumb代碼差不多，和純16位CPU相比相當有競爭力。 但是沒有免費的午餐；MIPS16程序可能比MIPS增加40-50%的指令。這意味著在CPU核上運行一個程序會多用40-50%的時鐘周期。但是低端CPU經常主要被存儲器所限制，而不是被CPU核所限制。較小的MIPS16程序需要較低的帶寬來取指令，這樣就得到更低的cache缺失率。在cache很小並且程序的存儲器有限時，MIPS16將會彌補差距，還有可能要重新改寫正常的MIPS代碼。 由於性能的降低，MIPS16代碼在有大的存儲器資源和很寬總線的計算機中沒有吸引力。這就是為什麼它只是一種可選擴展的原因。 在應用范圍的另一端, MIPS16將會與軟件壓縮技術展開競爭。在放進ROM存儲器之後，使用通常的文件壓縮算法壓縮的正常MIPS程序將會比未壓縮的同等MIPS16代碼小，而稍大於壓縮過的MIPS16同等代碼(注1)；如果你的系統擁有足夠的內存能夠把ROM當做文件系統使用，而把代碼解壓縮到RAM中執行，那麼全ISA軟件解壓很可能會帶來更好的總體性能。 也有這樣一種趨勢來構造系統，那就是大量使用以字節編碼的解釋語言(Java或者它的後續者)來書寫大量在時間上要求不嚴格的程序。那種中間代碼非常小，在尺寸方面比任何二進制機器碼都高效的多。如果只有解釋器和一些對性能要求嚴格的程序留在機器中ISA中，那麼更密集的指令集編碼格式將只會影響程序的一小部分。當然解釋器(特別是Java)本身會非常大，但是應用復雜度的無情增長將很快使它減少重要性。 我預料在1998-2003年將會看到MIPS16小范圍的應用於低能量、小尺寸和成本受限制的系統中。它還是值得發明的，因為有些系統—比如”智能”移動電話—可能會大量生產。 1．更密集的編碼格式在使用上比壓縮算法有更低的冗余度。 D.2 MIPSV/MDMX MIPS V和MDMX是在1997年早些時候一起公布的。它們本來是為一種新的准備在1998年發布MIPS/SGI的CPU中的指令而設計的。但是那個CPU後來被取消了，關於它們的未來存在疑問。 二者都是為了克服一些已知的傳統指令集的不足，這些不足是在ISA面向多媒體應用中產生的。象軟調制解調器的語音編/解碼、或流媒體應用、或圖像/視頻的壓縮/解壓縮這樣的任務采用一些過去只有專用數字信號處理器(digital signal processor, DSP)才用的數學算法。在這種計算等級，多媒體任務通常都包括重復進行一些對大向量或者數組數據的相同操作。 在基於寄存器的機器內部，通常采用的方案是把多媒體數據項封裝到一個機器寄存器中，然後執行一條寄存器-寄存器指令，這條指令對於每個寄存器中的每個域做同樣的工作。這是一種非常明顯的並行處理形式，被稱為單指令，多數據(single instruction, multiple data. SIMD)。 這個想法首先見於一款Intel的業已消失的i860架構的微處理器(circa 88)中。作為對Intel x86指令集進行擴展的MMX在1996年投放市場後，SIMD重新登場時更加引人注目。 MDMX對操縱在一個64位寄存器中8x8-bit的整數組提供了一組操作，這些操作能夠對所有的8小片做同樣的事情。這些指令包括通常的算術操作(加，減，乘)，也有乘法-累加指令能把結果放在一個巨大的累加器中，這個累加器有足夠的精度防止溢出。 由於這些指令被用於特定數據類型被相當清楚的從正常的程序變量分離開來的場合中，MDMX指令集與浮點寄存器一起工作就變得有意義。以這種方式重復利用現有的寄存器意味著現有的操作系統不需要改變(在任務切換時操作系統已經保存和恢復浮點寄存器了)。 與MDMX相似，Intel的MMX為封裝進一個64bit的8個8bit數提供了”octibyte”八路(eight-way)指令。MIPS MDMX也定義了4x16位(四個短整數操作)和2x32位(兩個字操作)格式，但是早期的情況是一些MDMX實現可能認定octibyte格式和指令足夠了。 當對8bit的數做算術運算時, 結果經常下溢和上溢。如果我們必須為眾多的溢出測試條件編寫處理程序，那麼多媒體應用的性能將不會得到提高。而只簡單截去最大的和最小的數(對於無符號8-bit數來說，就是255和0)的上溢和下溢結果，對於機器運算來說會更加有幫助。這個處理過程叫做”飽和”(saturating)算法。MDMX擁有這種能力。 這就給我們帶來了MIPS V。盡管從名字上看好像意思是指一個升級的指令集--就像MIPS I到IV那樣，MIPS V在浮點領域跟MDMX很相似，提供了paired-single操作。paired-single對一對被封裝進64-bit的浮點寄存器中的單精度數做兩次FP動作。 MIPS V沒有MDMX那麼古怪；MIPS IV包含了一個相當廣泛的浮點運算集合，並且直接為其中的絕大部分提供了paired-single版本的指令；甚至成對比較(paired-compare)也可以做到，這是因為MIPS IV的CPU已經有了多個浮點條件位來接收結果。但MIPS V沒有提供復雜多周期指令的成對操作版本的指令，這些多周期指令會需要非常多新的資源(例如沒有求平方根和除法)。 D.2.1 編譯器能用多媒體指令嗎？ 引入SIMD多媒體指令的原因和70年代晚期以前在超級計算機中提供向量處理單元的原因相似。很容易為向量處理器構造一個手工矩陣算術包。而用向量運算來編譯一個用高級語言寫成的程序就難得多了，盡管超級計算機提供商在這上面也取得一些成果。通常這些成果都集中在Fortran上；對於常規編程來說語義上的弱點使Fortran成為一種可憐的語言，但是這讓它變成了一種很容易優化的語言
