你能告訴我匯編程式如何處理 FC=00,01,10 和 11 的值嗎？
當我在我的匯編器上執行指令時 - 我發現 FC=11。但我不知道這意味著什么。
uj5u.com熱心網友回復：
2 位fc欄位和后面的 4 位一起，實際上只是 6 位func欄位。
我不知道為什么那些作者選擇將其分成兩個并排的欄位，因為它似乎沒有我能看到的特定目的。
此外，雖然它們僅針對這幾條指令將欄位分成兩部分，但對于所有其他指令描述func，它們恢復為對 6 位欄位的描述。func
由于這種記法，在查找0x0、0x1、0x2、0x3的欄位fc，后面4位為0xc時，我們也可以查找func0x0c、0x1c、0x2c、0x3c的欄位值，其中一些可以找到.
0x3c的func值用于（當然，對于單人與雙人，c.lt.s/d正確的opcode=0x11 和=0x10/0x11）。fmt
欄位值func0x0c 用于round.w.s/d.
其他值 0x1c 和 0x2c 在檔案中找不到，這種遺漏是未使用操作碼的典型特征，因此一種可能性是這些確實是 R2000 未使用的操作碼。
在https://disasm.pro/ (MIPS/big-endian) 中輸入 46 00 00 3c會產生正確的c.lt.s，而 46 00 00 0c 會產生預期的round.w.s，而以 1c 或 2c 結尾則不會產生反匯編。
另一個來源MIPS green sheet提供了相同的答案：0x0c 用于舍入，0x3c 用于比較，而 0x1c 和 0x2c 顯示為未分配。
我們期望處理器對未分配的操作碼做什么？它不清楚，通常沒有詳細說明。檢測這些東西需要作業，因此設計人員可以允許實作做最方便的事情（即最低的硬體作業量）。因此，未指定可以是遺漏，甚至可能被明確定義為未定義的行為！執行的可能性范圍從導致某種例外/故障（未實作）到不正確地解碼指令，這可能意味著運行非常相似編碼的指令。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/530351.html