複数のバイト値はどのように変換されますか？

Question

文字はcharで、サイズは1バイトかもしれませんが、例えば、intという4バイトの値になると、CPUはバイトごとに4文字ではなく整数とどのように違いますか？

Answer 1

一般に、CPUは特定のメモリ位置に格納された値の解釈については何も知らず、それを知っているはずの正しいコードを実行する（この場合、コンパイラによって生成される）そのような値を操作するCPU命令。

別の言い方をすると、変数の型は、メモリを操作するために生成するコードをコンパイラに知らせる言語の抽象です。何らかの方法で

タイプは、マシン・コード・レベルで存在します：様々な種類の上で動作する各種の指示があった - メモリに保存された生の値を解釈する方法、すなわち、それが正しいを使用するために実行されるコード次第ですメモリに格納された値を正しく処理するための命令。

Answer 2

コンパイラには「シンボルテーブル」という名前のテーブルがあります。したがって、コンパイラはどのタイプがvarであるか、どのようにそれを考慮する必要があるかを認識します。

Answer 3

CPUの設計について質問がありますか？

各CPUマシン命令は、CPUが動作するビット数を知るようにエンコードされています。

C++コンパイラは、charの8ビット命令とintの32ビット命令を発行することを認識しています。

Answer 4

これはアーキテクチャによって異なります。ほとんどのシステムでは、整数値にIEEE 754 Floating Point RepresentationとTwo's Complimentを使用していますが、問題のCPUまでです。これらのバイトを「値」に適切に変換する方法はわかっています。

Answer 5

CPUは、作成したコードを実行します。
は、「0x87367番地の4バイトを整数として扱い、値に1を加える」のように、特定のメモリの数バイトをで処理する方法をCPUに伝えます。

メモリをどのように扱うかを決めるのはあなただ。

Answer 6

CPU側では、主にレジスタと命令セットの2つが関係します（たとえば、x86参照）。

registerは、CPUに最も近いメモリの小さなチャンクです。値はそこに置かれ、そこでは基本的な操作を行うために使用されます。

命令セットには、レジスタ上のメモリスロットをアドレス指定する固定名（EAX、AXなど）のセットが含まれます。名前に応じて、それらはより短いまたはより長いスロット（例えば、8ビット、16,32,64など）を参照することができる。これらのレジスタに対応して、あるサイズのレジスタ値にも作用する演算（加算、乗算など）があります。 CPUが命令を実際に実行する方法やレジスタを格納する方法は関係ありません（CPUの製造元の裁量に委ねられています）。命令セットを正しく使用するのはプログラマ（またはコンパイラ）の責任です。

CPU自体は何をしているのかわかりません（「インテリジェント」ではありません）。要求されたとおりに動作します。コンパイラは、変数のタイプを追跡し、プログラムによって生成され、後で実行される命令が、コード化されたものに対応することを確認するものです（「コンパイル」と呼ばれます）。しかし、いったんプログラムがコンパイルされると、CPUはタイプやサイズなどの「追跡」をしません（あまりにも高価になります）。コンパイラは一貫性のある命令を生成することが保証されているので、これは問題ではありません。もちろん、アセンブリで独自のコードをプログラムし、不一致のレジスタと命令を使用しても、CPUは気にしません。プログラムが非常に奇妙な（クラッシュする可能性があります）ようになります。

Answer 7

内部的には、CPUが4ビットの8ビットオクテット（バイト）に変換される32ビットの整数をフェッチするように配線されている場合があります。 CPUはフェッチを4バイトではなく32ビットと見なします。

CPUは、文字（バイト）の8ビットをフェッチするために内部的に配線されています。多くのプロセッサアーキテクチャでは、CPUがメモリから32ビットをフェッチし、使用されていないビットを内部的に無視します（最下位の8ビットを保持します）。これは、32ビットのフェッチのみを要求することによってプロセッサアーキテクチャを単純化する。

効率的なプラットフォームでは、32ビット単位でメモリにアクセスすることもできます。メモリからプロセッサへのデータフローは、多くの場合、データバスと呼ばれます。この説明では、の32ビット幅となります。

他のプロセッサアーキテクチャでは、キャラクタに8ビットをフェッチできます。これにより、プロセッサが32ビットフェッチから3バイトを無視する必要がなくなります。

一部のプログラマは整数をビットではなくバイトの幅で表示します。したがって、32ビットの整数は4バイトと考えることができます。これは、特にビット順序付け、a.k.a.Endianessとの混乱を招く可能性があります。いくつかのプロセッサは最上位ビット（ビッグエンディアン）を含む第1のバイトを有し、他のプロセッサは最下位ビット（リトルエンディアン）を表す第1のバイトを有する。これにより、プラットフォーム間でバイナリデータを転送するときに問題が発生します。

プロセッサの整数が4バイトを保持できることと、一度に4バイトをフェッチすることを知っているプログラマの多くは、パフォーマンスを向上させるために4文字を整数にパックすることを好む。したがって、プロセッサは、4文字に対して4つのフェッチを行うのではなく、4文字に対して1フェッチを必要とする。このパフォーマンスの向上は、整数から文字をパックして解凍するのに必要な実行時間によって浪費される可能性があります。

要約すると、整数を構成するバイト数と、文字またはバイト数の関係を忘れることを強くお勧めします。この概念は、いくつかの組み込みプラットフォームまたはいくつかの高性能アプリケーションにのみ関係します。あなたの目的は、一定の期間内に正確で堅牢なコードを提供することです。パフォーマンスとサイズに関する懸念はプロジェクトの終わりにあり、誰かが苦情を申し立てた場合にしか苦にならない。メモリの占有量ではなく、整数の範囲と限界に集中すれば、あなたのキャリアでうまくいくでしょう。