CPUがデータをL1iとL1dのどちらに配置するかを決定する方法
CPUは、メモリから取得したばかりのデータを格納するために使用するキャッシュをどのように決定しますか？
私の知る限り、CPUがアクセス（読み取りまたは書き込み）できるメモリの最小単位は64バイト（x86_64、DDR3/DDR4）で、8回の転送（64ビットx 8回）のバーストで送信されます。この64Bユニットは、到着するとすぐにL1に格納されるためキャッシュラインと呼ばれます（各エントリは64B +タグです）。
コンパイルされたコードは命令でいっぱいで、データはインターリーブされています-多くの命令は命令自体の一部としてデータを持っています-オペコードの後に即時データが続きます。これは全体が命令と見なされ、L1iに格納されますか？ L1iとL1dの両方のエントリは64B幅ですか？キャッシュライン全体がL1iまたはL1dのいずれかに保存されていますか？それとも、CPUがCの.dataセグメントを認識していて、プログラムのその部分からのデータのみがL1dに格納されているということですか？もしそうなら、それはどのように知っていますか？
CPUは、メモリから取得したばかりのデータを格納するために使用するキャッシュをどのように決定しますか？
CPUは、使用するキャッシュを"decide"にする必要はありません。キャッシュの割り当ては、プロセッサのキャッシュロジックに組み込まれています。 CPUは、各メモリアクセスの理由と目的を認識しています。
コンパイルされたコードは、インターリーブされた命令とデータでいっぱいです...
それは誤ったアサーションです。
コードセクションとデータセクションをブレンドしたコンピューターを使用しましたが、それはマイクロプロセッサーの登場よりも前のものでした。
最新のCPUアーキテクチャは、ハードウェアスタックを使用して、再帰とシリアル再入可能コードを容易にします。
最新のツールチェーンは、コード共有を容易にするために、個別のテキスト（つまりコード）とデータセクションを生成します。
ハーバードコンピュータアーキテクチャの顕著な特徴は、コードとデータ用の個別のメモリです。
最も広く使用されているコンピューターは、プリンストンまたはフォンノイマンアーキテクチャに準拠していますが、現代の傾向は、ハーバードアーキテクチャの側面を組み込むことです。
命令とデータに別々のキャッシュを使用すること（ただし、単一のメインメモリアドレス空間）は明らかな例です。
...多くの命令には、命令自体の一部としてデータが含まれています。オペコードの後に直接データが続きます。
これは、命令フォーマットの不正確な説明です。
CPU命令は、オペコードと0個以上のオペランドで構成されています。
- HALTなどのオペコードにはオペランドがありません。
- オペランドは、レジスターの内容への参照、またはオペランド自体の値（別名、即値またはリテラル値）である可能性があります。このような命令は、（データ）メモリ操作を生成しません。
- オペランドは、メモリアドレス、メモリアドレスとしてのレジスタの内容への参照、またはアドレスオフセットの場合があります。メモリアドレスの計算を指定するために、アドレスモードやレジスタに追加のオペランドが存在する可能性があります。このような命令は、（データ）メモリ操作wh en実行を生成します。
これは全体が命令と見なされ、L1iに格納されますか？
命令は、オペコードと0個以上のオペランドで構成されます。
命令がデコードされるまで（特に固定長 RISC命令の場合）、命令のオペランド部分は謎であり、キャッシュロジックによって分離できませんでした。
もちろん、命令全体を単一のエンティティとして保持する必要があり、（命令が実行されるまで）データキャッシュに関与することはありません。
命令キャッシュは、命令としてフェッチされたメモリ位置のみを保持します。
これらの命令のメモリアドレスは、PC（プログラムカウンタレジスタ）によって指定されます。
CPUが分岐予測ロジックを採用している場合、それは命令のアドレスの別のソースである可能性があります。
他のすべてのメモリ参照は、データへのアクセスと見なされます。
私の知る限り、CPUがアクセス（読み取りまたは書き込み）できるメモリの最小単位は64バイト（x86_64、DDR3/DDR4）で、8回の転送（64ビットx 8回）のバーストで送信されます。この64Bユニットは、到着するとすぐにL1に格納されるためキャッシュラインと呼ばれます（各エントリは64B +タグです）。
.。
L1iとL1dの両方のエントリの幅は64Bですか？キャッシュライン全体がL1iまたはL1dのいずれかに保存されていますか？
キャッシュサイズはCPUの実装に依存します。
そのような仕様について一般化しようとすると不正確になります。
他にも多くの（最新の）CPUアーキテクチャと実装があり、あなたが説明したり主張したりするものとは似ていません"know"。
それとも、CPUがCの.dataセグメントを認識していて、プログラムのその部分からのデータのみがL1dに格納されているということですか？もしそうなら、それはどのように知っていますか？
いいえ、CPUはメモリ構成を認識していませんが、メモリアクセスの理由と目的を認識しています。
プログラムカウンタ（PC）レジスタ（およびその他の可能なロジック）からのアドレスを使用するメモリアクセスは命令用であり、命令キャッシュを利用します。
命令のexecutionは、データのメモリアクセスを生成でき、そのメモリアクセスはデータキャッシュを利用します。
コードとデータがソフトウェア生成ツールによって分離されていなくても、読み取り/書き込みデータキャッシュが読み取り専用命令キャッシュと重複している場合は予測できない結果が発生しますが、CPUは別々のコードキャッシュとデータキャッシュを使用できます。 。
データと命令はバスと高レベルのキャッシュでインターリーブされる場合がありますが、CPUはいつでも処理しているデータのタイプを認識しています。
バイトはL2キャッシュからストリーミングされ、命令のタイプを識別して監視できます。プログラムフローを推測して監視および調整し、必要に応じてキャッシュをフラッシュできます。 CPUによって実行された最初の命令から、「命令ストリーム」を確認できるため、命令キャッシュに何を入力する必要があるかを確認できます。
何がその最初の指示を与えますか？
どのコンピュータでも、最初に取得するのは命令です。 CPUが最初に行うことは、特定のアドレスに移動して、数バイトを取得することです。歴史的にこれはROMデバイスですが、CPUに起動命令とマイクロコードを渡すPCHのメモリマップドデバイスでも同じくらい簡単です。
現在の（したがって次の）命令へのポインタは、 プログラムカウンタ として知られるCPUのレジスタです。命令が実行されると常に更新されます。
実際、最初のいくつかの命令は単に「プログラムカウンタをxxxxxxxxxに設定」することができ、その時点でプロセッサは別のメモリデバイスが存在する可能性のあるその場所から命令を取得するように切り替わります。
そこから、CPUは常に命令ストリームを可視化します。命令、分岐、チェックなどの後に命令を見ることができます。オペレーティングシステムがCPUを停止してCPUを再起動すると、実行を開始する命令の正確な場所がプログラムカウンタにロードされます。
そこから、CPUは再び先を見越して、命令ストリームと、命令キャッシュにロードする必要があるものを確認できます。
残っているものすべてにデータキャッシュがあります。