[請益] CPU指令解碼的解譯優先順序

[erspicu (.)]

https://dl.dropboxusercontent.com/u/61164954/homepage/files/20130420/arm.png

覺得很奇怪的是,記得我以前上課的時候,

老師有說cpu一定會有某些特定的位元組來做指令的區分,

不可能有衝突的可能,按照這個說法如果我們軟體讀取資料做解譯,

我們也只要對幾個特定的BIT做mask,然後比對是否符合特定的數值,

就可以知道資料是什麼指令,該用什麼方式去解讀,因此我們可以用好幾個

if ( (ins & 0x?????? ) == 0x?????? )
{
  //某個指令
} else if (....)
{
  //某個指令
} else if (....)
{
 //某個指令
} ......

判斷來寫出解譯器,不過實際上我卻發現會因為判斷前後順序的不同,

導致最後解出不同的指令,很奇怪的問題... 還是我的觀念有誤?

又另外我要怎麼知道判讀的前後優先順序?

我抓到的DataSheet 只有把所有指令格式列出,

但是它並沒有說明cpu會優先用哪種格式去做解讀.

實際上判讀的前後順序,某些少部分情況下真的會影響到結果.








--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.70.79.227
推 Ting1024:仔細看一下衝突的兩個指令集格式，還可以再細分其不同
→ manlike:啊不就 op code  = =
→ akasan:不會是在說 lsl 跟 mov 這種例子吧
後來想一想,得到的結論是使用特定BIT做mask,檢查mask後是否符合特定的數值,
這種做法的確有前後順序需要處裡的問題,似乎是看mask的數值,
越小的要留到越後面去解,RISC的cpu不知道,
CISC的arm在寫解譯器或是模擬器就要注意到.

不過後來想想這些問題,丟在這裡應該也很難獲得比較正確結論,
還是多靠自己好了.
※ 編輯: erspicu         來自: 61.70.79.227         (04/21 12:26)
→ yyc1217:建議你看一下白算盤或紅算盤，CPU解OP碼不是用軟體解的
當然不是用軟體,但是用軟體也可以,不然就不會有解譯跟模擬器了.
推 ggg12345:cpu都是用多層decoder對不同欄位解碼產生模組選擇與控制
→ ggg12345:訊號.看該CPU的指令集手冊才是正解,disasm會看錯譯錯嗎?
→ ggg12345:解碼電路通常都全解,IF-then-else易犯片面覆蓋的不週密錯
推 tingyushyu:ARM的opcode的bit長度不一 不是看某幾個bit就能判斷的
這個問題我也想過,所以disasm會讓你選擇用什麼方式去解讀,有些還auto模式自行判斷,
比較好奇的是auto是靠什麼機制的,最後猜測是它是解譯器兼模擬器動態判斷.
※ 編輯: erspicu         來自: 61.70.79.227         (04/21 21:09)
→ chingwuen:沒有ELF很難直接看出是Thumb還是ARM指令集
→ chingwuen:除了依據最低bit判斷外, 平常branch後有X 就會自動切
→ chingwuen:如果程式正常一步一步跑 BLX,BX就會自動切換指令集模式,
→ chingwuen:如果碰到異常狀況, 像stack overflow蓋到備份的LR值
→ chingwuen:會造成PC跳到奇怪的地方. 有可能目前指令集模式看不出來
→ chingwuen:就會有CPU undefined instruction exception
→ chingwuen:CPSR有個T flag就是指說目前CPU是不是以Thumb mode執行
→ ggg12345:好奇問一下?想做disasm嗎?這不是已有工具?聽說有案子出錢
→ ggg12345:用此法想抓盜拷,但此法足以證明嗎?很想知道是想做甚麼?
先實作DISASM後,確認無誤後,朝向CPU模擬器實作,最後再實作gba的相關功能部分,
想嘗試寫看看gba模擬器,不過我的硬體底層背景很弱,程式倒不是太大問題,
只是缺少相關知識背景,得補很多東西,也許中途就因為缺乏動力放棄掉了也不一定,
純好玩,所以萬不得以不太想靠其他opensources的東西去port,這就跟原來用義不同了.
※ 編輯: erspicu         來自: 61.70.79.227         (04/22 00:30)
→ hilorrk:還是可以參考 qemu 之類的檢視一下自己的錯誤囉