ROMに保存されている実行可能ファイルについて基本的な疑問があります。
私が知っているように、テキストとRO属性を持つ実行可能ファイルはROMに保存されています。質問は、ROM は読み取り専用メモリ用であるため、コードをメモリに書き込む必要がある場合はどうなりますか?
ここで引用する例を思い出すことはできません (おそらく、私はそのような状況を知らないか、基本的なことを見逃しています ;) が、このトピックに関する光は、私が理解するのに大いに役立ちます! :)
最後に - 1.そのような状況はありますか? 2. そのような場合、コードを ROM から RAM にコピーするのが答えですか?
いくつかの例で答えてください..
よろしくお願いします！
/MS
読み取り専用メモリは、ハードウェアの制限により読み取り専用です。プログラムは、EEPROM、書き込みから保護されたフラッシュ メモリ、CD-ROM、またはハードウェアが物理的に書き込みを許可しないものにある可能性があります。ソフトウェアが ROM に書き込む場合、ハードウェアは格納されたデータを変更できないため、何も起こりません。
そのため、 ROM内のソフトウェア プログラムがメモリに書き込みたい場合は、RAMに書き込みます。それが唯一の選択肢です。プログラムが ROM から実行されていて、それ自体を変更したい場合、ROM に書き込むことができないため変更できません。しかし、はい、プログラムは RAM から実行できます。
実際、最小の組み込みシステムを除いて、ROM から実行することはほとんどありません。オペレーティング システムは、実行可能コードを実行する前に ROM から RAM にコピーします。場合によっては、コードがROM で圧縮されているため、実行する前に RAM に解凍する必要があります。RAM がいっぱいになると、オペレーティング システムはページングを使用して RAMを管理します。ROM からの実行が非常にまれな理由は、ROM が RAM よりも遅く、実行前にローダーによってコードを変更する必要がある場合があるためです。
自分自身を変更するコードがある場合は、実際にシステムを理解する必要があることに注意してください。多くのシステムでは、データ実行防止(DEP) が使用されています。実行可能コードは、RAM の読み取り + 実行領域に入ります。データは読み取り+書き込み領域に入ります。したがって、これらのシステムでは、コードが RAM 内で変更されることはありません。
実行時にコード セクションを変更する正当な理由はほとんどありません。コンパイラ自体は、それを必要とするコードを生成しません。
リンカーには、MAP ファイルを生成するオプションがあります。これにより、すべてのメモリ オブジェクトが どこにあるかがわかります。
リンカーは、リンカー スクリプト (必要に応じてメモリを整理するためにカスタマイズできます) に基づいて、配置する場所を選択します。通常、FLASH ベースのマイクロコントローラ コードと定数データは ROM に配置されます。ROM には、ゼロ以外の初期化された静的データの初期化データも配置されます。これは、main() が呼び出される前に RAM にコピーされます。ゼロ初期化された静的データは、main() の前に単純にゼロにクリアされます。
リンカが ROM 内のコードの一部またはすべてを検索し、ランタイム スタートアップ コードがゼロ以外の静的データと同じ方法でそれを RAM にコピーするように設定することは可能ですが、コードは次のいずれかでなければなりません。再配置可能または最初のインスタンスで RAM に配置される場合、通常、ROM から RAM に実行することを目的としたコードをコピーして実行することを期待することはできません。これは、絶対アドレス参照が含まれている可能性があるためです (おそらくターゲットに MMU があり、アドレス空間)。マイクロコントローラーの RAM に配置するのは通常、実行速度を上げるために行われます。高クロック速度が使用されている場合、RAM は通常 FLASH よりも高速であり、待機状態が少ないかゼロになるためです。また、コードが ROM に格納されているのではなく、ファイルシステムから実行時に読み込まれる場合にも使用できます。RAMにロードしても、
通常、ROM にはプログラム コード、定数、および初期化データのみが格納されます。RAM 内の別のメモリ領域は、スタック、ヒープなどに使用されます。
多くの小型マイクロコントローラー (Microchip PIC、Atmel AVR、Intel 8051、Cypress PSoC など) はハーバード アーキテクチャを採用しています。プログラム メモリ (フラッシュまたは ROM) からコードを実行することしかできません。プログラム メモリから RAM に任意のバイトをコピーできます。ただし、(2)実行可能な命令を ROM から RAM にコピーすることは答えではありません。これらの小さなマイクロコントローラーでは、プログラム カウンターは常にプログラム メモリ内のアドレスを参照します。RAM でコードを実行することはできません。
ROM から RAM へのデータのコピーはかなり一般的です。最初に電源が投入されると、一般的なファームウェア アプリケーションはすべての RAM をゼロにし、main() が開始する直前に非 const グローバル変数と静的変数の初期値を ROM から RAM にコピーします。アプリケーションが固定文字列をシリアル ポートからプッシュする必要があるときはいつでも、その文字列を ROM から読み取ります。
これらのマイクロコントローラの初期のバージョンでは、マイクロコントローラに接続された外部の「デバイス プログラマ」がプログラムを変更する唯一の方法です。通常の操作では、デバイスは「デバイス プログラマー」にはほど遠いものでした。マイクロコントローラ上で動作するソフトウェアがプログラム メモリ ROM に書き込む必要がある場合、申し訳ありませんが、それは不可能でした。多くの組み込みシステムには、コードを書き込むことができる不揮発性 EEPROM がありましたが、これはデータ値を格納するためだけのものでした。マイクロコントローラは、EEPROM や RAM ではなく、プログラム ROM 内のコードしか実行できませんでした。人々は、BASIC インタープリターやバイトコード Forth インタープリターなど、これらのマイクロコントローラーで素晴らしいことをしたかもしれません。したがって、明らかに(1)コードがプログラム メモリに書き込む必要はありません。
最近の「自己プログラミング」マイクロコントローラー (Atmel、Microchip、Cypress など) のいくつかでは、チップ上に特別なハードウェアがあり、マイクロコントローラーで実行されているソフトウェアが独自のプログラム メモリ フラッシュのブロックを消去および再プログラムできるようになっています。一部のアプリケーションでは、この「セルフ プログラミング」機能を使用して、「余分な」フラッシュ ブロックのデータを読み書きします。データは実行されないため、自己変更コードとはみなされませんが、これは何もしていません。より大きなEEPROMではできませんでした。これまでのところ、新しい実行可能ソフトウェアを独自のプログラム フラッシュに書き込む、ハーバード アーキテクチャのマイクロコントローラーで実行されるソフトウェアは、ブートローダーと Forth コンパイラーの 2 種類だけです。
Arduino ブートローダー (ブートストラップ ローダー) が実行され、新しいアプリケーション ファームウェア イメージが利用可能であることを検出すると、新しいアプリケーション ファームウェアを (RAM に) ダウンロードし、フラッシュに書き込みます。次にシステムの電源を入れると、古いバージョンの 16.97 アプリケーション ファームウェアではなく、ピカピカの新しいバージョン 16.98 アプリケーション ファームウェアが実行されます。(もちろん、ブートローダー自体を含むフラッシュ ブロックは変更されません)。これは、プログラム メモリへの書き込みの「セルフ プログラミング」機能がなければ不可能です。
一部の Forth 実装は、小さなマイクロコントローラー上で実行され、新しい実行可能コードをコンパイルし、「セルフ プログラミング」機能を使用してそれをプログラム フラッシュに格納します。このプロセスは、JVM の「ジャスト イン タイム」コンパイルに似ています。(他のすべての言語は、小さなマイクロコントローラーで実行するには大きすぎて複雑なコンパイラーを必要とするため、編集、コンパイル、ダウンロード、実行のサイクルにはるかに長い時間がかかります)。