私は現在、ARM7tdmi プロセッサに基づくビデオ ゲーム コンソール エミュレータを作成しており、プロセッサが正しく機能しているかどうかをテストしたい段階にほぼ入っています。コンソール全体の CPU とメモリの部分しか開発していないため、プロセッサをデバッグする唯一の方法は、ログ (コンソール) システムを使用することです。これまでのところ、ダミーのオペコードをフェッチしてランダムな命令を実行するだけでテストしました。プロセッサが正しく機能していることを確認するために、この種の目的のために特別に設計された実際の ARM7 プログラム (または他の方法論) はありますか? 前もって感謝します。
次のようなダミー オペコードを使用しました。
ADD r0、r0、r1、LSL#2
MOV r1、#r0
ただし、32ビットのオペコード形式です。
また、いくつかのテストを作成し、GBA エミュレーターでいくつかのバグを発見しました。私はまた、独自のエミュレーターを作成しました (プロセッサーとボードをテストするプロセッサー・ビジネスでの作業も同様です)。
定期的にやっていることがいくつかあります。これらは私の一般的なテスト方法論です。
zlib やその他の圧縮ライブラリ、jpeg、mp3 など、多数のオープン ソース ライブラリがあります。データのチャンクとポインタを使用して fopen、fread、fwrite を偽造し、これらをベアメタル化することは難しくありません。ターゲットプロセッサでセルフテストできる圧縮ライブラリと暗号化とハッシュ。何かを圧縮し、それを解凍し、オリジナルと圧縮されていないものを比較します。また、テスト対象のコードをホストで実行し、圧縮バージョンと解凍バージョンのチェックサムを計算し、ハードコードされたチェック値を提供してから、ターゲット プラットフォームで実行することもよくあります。jpeg、mp3、またはハッシュ アルゴリズムの場合、テスト対象のコードのホスト バージョンを使用してゴールデン バリューを生成し、それをターゲット プラットフォームで比較します。
それを行う前に、フラグ、特にキャリーフラグ（および符号付きオーバーフロー）を正しく取得するのは非常に難しいですが、一部のプロセッサは、減算操作の場合にキャリーアウトフラグを反転します（減算は、2番目のオペランドのものを補う加算です）キャリーイン 1 の補数 (キャリーなしの通常の加算はゼロのキャリーインであり、キャリーなしの減算は、2 番目のオペランドが反転されたキャリーインと 1) の加算です)。そして、そのキャリーアウトの反転は、キャリーが途中で反転されているかどうかに関係なく、命令セットにボロー付き減算がある場合、キャリーオンに影響します。
特定のプロセッサがキャリーをどのように管理するかについては、条件分岐の定義 (C がこれで V がそれの場合、C がこれで Z がそれの場合) から明らかな場合があります。 (符号なしオーバーフロー) および符号付きオーバーフロー フラグは、実際のシリコンで実験する必要はありません。どのプロセッサが何をするのか覚えていません。命令セットごとに把握しているので、ARMが何をしているのかわかりません。
ARMには、注意が必要なシフト操作のニュアンスがあり、適切に実装されていることに注意してください。各命令の疑似コードを読んでください。シフト量== 32の場合はこれを行い、シフト量== 0の場合はそれを行い、そうでない場合は他のことを行います. arm7 を使用すると、障害が無効になっている場合にアラインされていないアクセスを行うことができ、32 ビット内でデータをローテーションするか、またはそのようなものになります。アドレス 0 の 32 ビットが 0x12345678 の場合、アドレス 1 で 16 ビットを読み取ると、バス上で 0x78123456 のような値が得られ、宛先は 0x3456 になります。うまくいけば、ほとんどの人はそれに依存しませんでした。しかし、ARM ARM のそれとその他の「予測不可能な結果」のコメントは、ARM ARM から ARM ARM に変更されました (異なるハードコピーのマニュアルがいくつかある場合、これはより明白になります。古い白く覆われたもの（細いものと厚いもの）と青い覆われたもの）。したがって、読んだマニュアル (armv4 プロセッサの場合) によっては、何かを行うことが許可されている場合と、許可されていない場合があります。そのため、1 つのマニュアルだけに頼っていると、予測できないと思われることを実行するコード/バイナリが見つかる可能性があります。
異なるコンパイラは異なるコード シーケンスを生成するため、異なるアーム コンパイラ (clang/llvm と gcc が最初の選択肢であることは明らかです) を見つけることができれば、他のコンパイラの評価コピーを入手してください (Kiel はおそらく良い選択であり、現在はアームによって所有されていると思います)。 Kiel と RVCT arm コンパイラの両方が含まれています)。同じテスト コードを異なる最適化設定でコンパイルし、それらのバリエーションをすべてテストして、コンパイラごとに繰り返します。テストに 1 つのコンパイラのみを使用すると、命令シーケンスにギャップが残り、コンパイラがそれらを生成しないためにテストされない多くの命令またはバリエーションが残ります。私はこの正確な問題に一度ぶつかりました。オープンソース コードを使用すると、さまざまなプログラマの習慣も得られます。それが asm であれ、C であれ、その他の言語であれ、個人によってプログラミングの習慣が異なり、その結果、さまざまな命令シーケンスと命令の組み合わせが生成され、プロセッサのバグを隠したり露出したりする可能性があります。これが 1 人の趣味のプロジェクトである場合、最終的には他の人に依存することになります。ここで gba や ds などのエミュレーターを使用すると、ROM の使用を開始すると大量の他の人のコードが作成され、残念ながらデバッグが困難になります。
Intel/x86 の設計検証担当者は、さまざまなオペレーティング システムを使用してプロセッサを打ち負かし、多くの混乱とバリエーションを生み出すという噂を耳にしました。プロセッサに負担がかかりますが、ROM と同様に、何か問題が発生した場合のデバッグが非常に困難です。私は、キャッシュや、私が取り組んだプロセッサ上で Linux を実行しているという個人的な経験があります。Linux を移植して起動するまでバグは見つかりませんでした。バグを見つけるのは非常に困難でした...幸い、arm7tdmi にはキャッシュがありません。キャッシュがある場合は、上記の組み合わせを使用し、コードに最適化レベルを掛けて異なるコンパイラーを掛けてテストし、ブートストラップまたは他の場所でそれに追加して、1、2、3、4 のバージョンをコンパイルします。
エミュレートしようとしている実際のハードウェアがあるこの場合、ランダムな alu マシン コードを生成するプログラムを用意する、ランダムに選択されたソース レジスタとデスティネーション レジスタを使用して数十の命令を生成する、加算、減算、および、またはしないをランダム化するなどのことができます。など、フラグのオンとオフをランダム化します。すべてのレジスタを事前にロードし、フラグを既知の状態に設定し、そのコードのチャンクを実行してから、レジスタとフラグをキャプチャして、実際のハードウェアと比較する方法を確認します。より複雑なプログラムの一部であるデータやフラグを実行するコードシーケンスをデバッグするよりも、これをデバッグする方が簡単です。
テストプログラムの組み合わせ、最適化設定を掛けたもの、コンパイラーを掛けたものなどを取り、割り込みで打ち負かします。割り込みのレートを変更します。これはシミュレーターなので、私が一度ハードウェアしたことを実行できます。割り込みでは、戻りアドレスを調べ、そのアドレスより数命令先のアドレスを計算し、そのアドレスを記憶します。割り込みから戻り、フェッチされているアドレスがプリフェッチ アボートを起動するのを確認したら、プリフェッチ アボート コードを用意し、(シミュレーションで) プリフェッチ アボートが起動したときにそのアドレスの監視を停止し、プリフェッチ アボート ハンドラのコードを(アームごとに) 中止が発生し、続行します。このセットアップでは、テスト中のプロセッサにかなりの苦痛を与えることができました...特にキャッシュをオンにした場合...
gba ゲームの大部分がサム モードであることに注意してください。これは、ほとんどが 16 ビット幅のデータ バスを使用するそのプラットフォームでは、サム コードが約 10 ～ 15% 多くの命令を必要とするにもかかわらず、サム モードはアーム モードよりも (はるかに) 高速に実行されるためです。バイナリ用の ROM スペースも少なくて済みます。armv4 は armv6 または 7 とは異なるアーキテクチャに基づくさまざまな実装があると思われるため、blx 命令を慎重に調べてください。よって、armv6 または 7 のマニュアルをリファレンスまたは検証用のハードウェアとして使用している場合は、それらの違いを理解してください。
何とか、何とか、何とかTL; 博士。とりとめのない申し訳ありませんが、これは私にとって楽しいトピックです...