2011-09-07 28 views
5

私は個人的/教育的プロジェクトとして解釈された68kエミュレータを書いています。今、私は単純で一般的な解読メカニズムを開発しようとしています。デコード68k命令

私が理解しているように、各命令の最初の2バイトは、(2つのまれな例外を除いて)操作を一意に識別するのに十分であり、ここで

は、私は私の復号化段階で達成したいものです。

1. read two bytes 
2. determine which instruction it is 
3. extract the operands 
4. pass the opcode and the operands on to the execute phase 

私はRISCアーチの最初の数ビットでできたように私は、ルックアップテーブルに最初の2つのバイトを渡すことはできませんなぜなら、オペランドは「途中」であるからです。どのように一般的な方法で部分2を達成することができますか?

私の質問は:どのようにして、デコードプロセスからオペランドの多様性を取り除きますか?

詳しい背景:ここ

は、プログラマーズリファレンスマニュアルのセクション8.2からの部分的なテーブルです:

Table 8.2. Operation Code Map 

Bits 15-12  Operation 
0000   Bit Manipulation/MOVEP/Immediate 
0001   Move Byte 
... 
1110   Shift/Rotate/Bit Field 
1111   Coprocessor Interface... 

これは私にとって大きな意味を成していたが、その後、私はそれぞれのビットパターンを見て命令は、ビット15-12が0001、0010、または0011である単一の命令がないことに注意してください。欠けているピクチャの大きな部分がなければなりません。

このDecoding Z80 Opcodesサイトでは、明示的にデコードを説明しています。これは、68kプログラマーのリファレンスマニュアルやグーグルで見つけられていないものです。

+0

プロジェクトがどのくらい成長しましたか、逆アセンブラまたはエミュレータがありますか? –

+0

私はまだ完全なルックアップテーブルを生成するスクリプトを構築しています。約70%が完了しました。 – mwcz

+0

@CountablyInfiniteあなたは同様のプロジェクトに取り組んでいますか? – mwcz

答えて

2

私は、各命令の可能なすべてのパターンを持つルックアップテーブルを作成することにしました。それは私の最初のアイデアでしたが、私はそれを「無駄な、控えめな」ものとして捨てました。今、私はそれを「本当に速い」と受け入れています。

+1

ああ、エミュレーターコーディングの最初のルールです。時にはclunky-looking brute-force approachが最高です1。 :) –

+1

それはエミュレーションを実行するCPUに大きく依存します。 16メガバイトのL2は不思議に作用することができます。 :) –