0

私は主に自動車ネットワーク設計を扱うソフトウェア会社の部門で働いています。ネットワーク プロトコル スタックは、主に C で記述します。最近、Freescale の HC12 コントローラを使用する必要のあるプロジェクトを任されました。最初に作成されたプロトコル スタックは、バンクされていない RAM と、バンクされているフラッシュとバンクされていないフラッシュの両方の使用をサポートしていました。私に割り当てられたプロジェクトでは、顧客は非バンク RAM の代わりにバンク RAM を使用することを要求しています (理由は不明です)。このプロジェクトの開発に取り組んでいるときに、far ポインターを使用してバンク RAM にアクセス (読み取り/書き込み) できることに気付きました。

私の質問は、far ポインターを使用してバンク RAM にアクセスしたときに、ライブラリ コードのサイズが 10k バイトも増加したことです。これは正常ですか？私が使用しているコンパイラ (codewarrior) のリファレンス マニュアルでは、通常のポインターのサイズが 2 バイトであるのに対し、far ポインターのサイズは 3 バイトであると記載されています。この余分な 1 バイトが、コード サイズに大きな違いをもたらすのでしょうか? バンクされた RAM にアクセスできる far ポインターの使用を含まない他の方法はありますか?

私の質問に対する有益な回答をいただければ幸いです。

4

2 に答える 2

2

当初、HCS12 のバンク メモリはフラッシュ内のプログラム コードにのみ使用されていたため、プログラム サイズに大きな違いはありません。唯一の違いは、サブルーチン呼び出しは、関数呼び出しごとに数バイト多くのプログラム メモリを必要とするバンク メモリ命令 (JMP、RTS ではなく CALL、RTC) を使用する必要があることです。

その後、バンク型フラッシュとバンク型 RAM の両方を備えたデバイスをリリースしました (一部の HCS12X など)。RAM は明らかにデータ用であり、プログラム メモリ用ではありません。

問題は、HCS12 が 16 ビット CPU であるため、24 ビット データ ポインターを簡単に処理できないことです。つまり、バンクされたメモリ内のデータを処理するすべてのコードはかなり非効率になります。アクセスごとに (「ファー」ポインターなどを介して)、24 ビット アドレスの上位 8 ビットを表すページ レジスタを設定する必要があります。それが完了すると、通常の命令でアドレスの 16 ビット部分にデータを読み書きできるようになり、ハードウェアはそれを正しいページにマップします。それが完了したら、プログラムはページ レジスタも復元する必要があります。

コンパイラがページ データへのアクセスを適切に最適化できない可能性は十分にあります。理論的には、ページ レジスタを設定し、そのページ内のすべてのデータにアクセスしてから復元する必要があります。ただし、コンパイル時に、コンパイラは変数がどこに割り当てられるかを正確に認識できない場合があります。

Codewarrior の逆アセンブラーを使用すると、実際にどのようなコードが生成されるかを簡単に確認できます。また、最適化に関しては、Codewarrior は常にかなり機能不全であることに注意してください。どの最適化を明示的に有効にする必要があり、どの最適化が「組み込み」であるかは明確ではありません。関連するすべての最適化が実際に有効になっていることを確認してください。

全体として、バンク メモリは可能な限り避けてください。最大 64k メモリの非バンク メモリ モデルを使用できます。ページ メモリが必要になるのは、その制限を超えたときだけです。おそらく、これが顧客がそれを必要とする理由であり、RAM が不足している可能性があります。

于 2016-03-15T09:57:24.640 に答える