ハーバードアーキテクチャはどのように役立ちますか？

私はarduinoとAVRアーキテクチャについて読んでいて、AVRのハーバードアーキテクチャの導入によってパイプラインのストールまたはバブリングがどのように解決されるのかという点で立ち往生しました。オペレーターなしでプログラムをロードできるようにしますが、上記の問題の解決にどのように役立ちますか？

偶然にAVRが発明されるずっと前に使用されたハーバードアーキテクチャは、実際にプログラムメモリとデータメモリ用に別々のアドレス空間を持っています。これが当事者にもたらすことは、プログラムメモリからのデータフローとデータメモリへの情報フローを処理するために、個別のバスと制御回路を使用できるように回路を設計する機能です。個別のバスを使用することは、データのメモリへの不定期なデータ転送から中断することなく、プログラムのフェッチと実行を継続できることを意味します。たとえば、アーキテクチャの最も単純なバージョンでは、プログラム取得ユニットは、前のプログラム命令の一部である可能性のあるデータ転送操作と並行して、プログラムシーケンス内の次の命令を取得するのに忙しくなります。

この最も単純なレベルでは、ハーバードアーキテクチャには、一般にプログラムコードをデータメモリに入れてそこから実行させることができないという制限があります。

私が説明したこのアーキテクチャの最も単純な形式の上に追加できる多くのバリエーションと複雑さがあります。よくある追加の1つは、命令キャッシュをプログラム情報バスに追加することです。これにより、命令実行ユニットは、必要なたびにプログラムステップをフェッチするために低速のメモリに移動することなく、次のプログラムステップにすばやくアクセスできます。

Michaelsの回答に加えて、いくつかのメモ：

1）ハーバードアーキテクチャでは、データとコード用に2つの別個のスペースが必要ではなく、2つの異なるバスを介して（ほとんど）フェッチされるだけです。

2）ハーバードアーキテクチャによって解決される問題は、バスの競合です。コードメモリがCPUをフルスピードで実行し続けるのに十分な速さで命令を提供できるシステムでは、データフェッチ/ストアの追加の負担によりCPUが遅くなります。ダウン。この問題は、ハードバードアーキテクチャ（CPUの速度に対して（少し）遅すぎるメモリ）によって解決されます。

キャッシングは、この問題を解決する別の方法であることに注意してください。多くの場合、ハーバードとキャッシュは興味深い組み合わせで使用されます。

ハーバードは2つのバスを使用します。2つに固執する固有の理由はありません。非常に特殊なケースでは、主にDSP（デジタルシグナルプロセッサ）で2つ以上が使用されます。

メモリバンキング（メモリアクセスを異なるチップセットに分散させるという意味で）は、データ/コードの区別ではなく、アドレスの特定のビットに基づいて、メモリシステム自体の内部の一種のハーバードと見なすことができます。

純粋なハーバードアーキテクチャでは、コードメモリとデータメモリ間でリソースを共有する必要がない場合、通常、特定のレベルの複雑さのコンピューターをVon Neumanアーキテクチャよりも高速に実行できます。ピン配置の制限または他の要因により、1つのバスを使用して両方のメモリ空間にアクセスする必要がある場合、そのような利点はほとんど無効になりがちです。

「純粋な」ハーバードアーキテクチャは、コードを実行するプロセッサ以外の何らかのメカニズムによってメモリに格納されるコードの実行に限定されます。これにより、工場（または特殊なプログラミング機器を持っている人）によって目的が設定されていないデバイスに対して、そのようなアーキテクチャの有用性が制限されます。この問題を軽減するには、2つのアプローチを使用できます。

一部のシステムには個別のコード領域とメモリ領域がありますが、コードバスを一時的に引き継いで何らかの操作を実行し、そのような操作が完了するとCPUに制御を戻すように要求できる特別なハードウェアを提供します そのようなシステムの中には、そのような操作を実行するためにかなり精巧なプロトコルを必要とするもの、そのようなタスクを実行するための特別な命令を必要とするもの、特定の「データメモリ」アドレスを監視し、アクセス試行時にテイクオーバー/リリースをトリガーするものもあります。このようなシステムの重要な側面は、「コード」と「データ」用に明示的に定義されたメモリ領域があることです。CPUが「コード」スペースを読み書きできる場合でも、データスペースとは意味的に異なるものとして認識されます。

いくつかのハイエンドシステムで使用される別のアプローチは、2つのメモリバスを持つコントローラーを使用することです。1つはコード用、もう1つはデータ用で、両方ともメモリアービトレーションユニットに接続します。そのユニットは、それぞれ個別のメモリバスを使用して、さまざまなメモリサブシステムに接続されました。1つのメモリサブシステムへのコードアクセスは、別のメモリサブシステムへのデータアクセスと同時に処理できます。コードとデータが同じサブシステムに同時にアクセスしようとした場合にのみ、どちらかが待機する必要があります。

このアプローチを使用するシステムでは、プログラムのパフォーマンスに重要ではない部分は、メモリサブシステム間の境界を単に無視する場合があります。コードとデータが同じメモリサブシステムにある場合、物事は別々のサブシステムにある場合ほど速くは実行されませんが、通常のプログラムの多くの部分は重要ではありません。典型的なシステムでは、パフォーマンスが本当に重要なコードの小さな部分があり、システムが保持するデータの小さな部分でのみ動作します。2つの8Kパーティションに分割された16KのRAMを備えたシステムがある場合、リンカー命令を使用して、パフォーマンスクリティカルなコードがメモリスペース全体の先頭近くに配置され、パフォーマンスクリティカルなデータが終わり。全体のコードサイズが9Kなどに増加した場合、最後の1K内のコードは他の場所に配置されたコードよりも実行速度が遅くなりますが、そのコードはパフォーマンスに影響しません。同様に、たとえばコードが6Kだけで、データが9Kに増えた場合、最低1Kのデータへのアクセスは遅くなりますが、パフォーマンスが重要なデータが他の場所にある場合、問題はありません。

コードが8K未満で、データが8K未満の場合、パフォーマンスが最適になりますが、前述のメモリシステムの設計では、コードとデータスペースの間に厳密なパーティションは設定されません。プログラムが1Kのデータのみを必要とする場合、コードは15Kまで増加する可能性があります。2Kのコードのみが必要な場合、データは14Kに増加する可能性があります。コード専用の8K領域とデータ専用の8K領域を持つよりもはるかに汎用性があります。

まだ議論されていない側面の1つは、通常16ビットのアドレスバスのみを備えた小型マイクロコントローラの場合、ハーバードアーキテクチャがアドレス空間を事実上2倍（または3倍）にすることです。64Kのコード、64KのRAM、および64KのメモリマップドI / Oを使用できます（システムがポート番号の代わりにメモリマップドI / Oを使用している場合、後者はすでにI / Oアドレス指定をコードとRAMスペース）。

それ以外の場合は、コード、RAM、およびオプションでI / Oアドレスをすべて同じ64Kアドレス空間内に詰め込む必要があります。