質問のオペコードの最大数は何ですか、答えはcオプションですが、各アドレスが各メモリ位置を指定するため、オプションアドレスdであると思います。これは、16個のアドレス行があるため、2 ^ 16アドレス、つまり2 ^ 16のメモリ位置。
したがって、各場所に1つのオペコードが含まれる場合、合計2 ^ 16個の場所に2 ^ 16個のオペコードが含まれ、これは最大数のオペコードですが、答えはcとして与えられます。これは2 ^ 12です。これはどのように可能ですか?
質問のオペコードの最大数は何ですか、答えはcオプションですが、各アドレスが各メモリ位置を指定するため、オプションアドレスdであると思います。これは、16個のアドレス行があるため、2 ^ 16アドレス、つまり2 ^ 16のメモリ位置。
したがって、各場所に1つのオペコードが含まれる場合、合計2 ^ 16個の場所に2 ^ 16個のオペコードが含まれ、これは最大数のオペコードですが、答えはcとして与えられます。これは2 ^ 12です。これはどのように可能ですか?
回答:
すべてのオプションが間違っています。プロセッサが実行できる(一意の)オペコードの最大数は、バス幅によって制限されません。
通常、12ビット以上のCPUは、ほとんどの命令を一度に読み取ることができるように、データワードごとに1つのコマンドを持つように設計されています。したがって、通常のCPUは2 ^ 12オペコードの制限まで設計されます。
2 ^ 12 = 4096を超えるオペコードを持つ既存のCPUアーキテクチャは、学習するのに多すぎる、実際に役立つには多すぎる、コストのかかるシリコンスペースを浪費するなど、それほど多く必要としないという理由で非常にまれです。
更新:コメントで指摘されているように、x86命令セットのすべての可能なバリエーションは、カウント方法に応じて実際に6000を超える可能性があります!ただし、これは例外です。
ただし、4ビットCPUの場合、2 ^ 4 = 16命令では十分でないことが非常に多いため、このようなプロセッサの多くにはさらに多くの命令があります。
CPUがデータバスに収まるよりも多くのオペコードを組み込む可能性のある複数の方法と理由があります。
プロセッサは、単一のデータサイクルでコマンドを読み取る必要はありません。結果として複数のサイクルを使用できます。実際、ほとんどのCPUはそうではありませんが、オペコードスペースを拡張するためではなく、命令引数としてより一般的に使用されています。
例:intel 4004には、データ/アドレスライン、4ビットデータワードとして多重化されている4行のみがありますが、8ビット命令では40以上のオペコードがあります。
(CISC)プロセッサには、必要な数の命令プレフィックスとサフィックスが含まれる場合があります。
それらは実際の命令の前に付けられて、その動作を変更します-少しまたは完全に。
「一意のオペコード」の定義に依存します。データではない命令の一部がオペコードの一部であると想定した場合、その総数には考えられるすべてのバリエーションが含まれます。ただし、これらの接辞は指導の別個の部分であると考える人もいます。
例:Intel x86 CPUには実際には4Mオペコードがありません。ただし、すべてのプレフィックスをオペコードの一部として数えると、最新のCPUでは15バイトまでの命令が許可されます。これは可能なオペコードの多くです。多くの人が同じことをしますが、これは「一意」であるという定義に依存します。
プロセッサには、完全に異なるオペコードのセットを持つ複数の動作モードがある場合があります。
例:intel x86_64には32ビット(real / v86 / protected)モードと64ビットモードがあり、それぞれに異なるオペコードがあります。ARM CPUには、ARM 32ビットモードとThumb 16ビットモードがあります。
質問には「データライン」と「アドレスライン」が記載されていますが、内部データバスと内部アドレスバスの両方が実際のバスラインの量よりも広い場合があります。
多重化されたバスデータは、順番に送信されます。つまり、前半、後半です。CPUはそれをフルサイズの内部レジスタに保存し、それらを操作します。
これは、コストやチップの物理的フットプリントサイズを削減するためによく行われます。
例としては、LPCデータバス上のインテル4004や、32行のデータバスしか持たないNintendo64のCPUであるNEC VR4300などがあります。
前のポイントの続きとして、CPUはパラレルバスをまったく公開する必要さえありません。
CPUは、I2C、SPIなどのシーケンシャルバスのみを簡単に公開できます。
そのような専用CPUを製造することはおそらくそれほど費用対効果が高くありませんが、多くの低ピン数のマイクロコントローラー(CPUとメモリの両方を含む)は、それらの貴重なピンをより有用なものに保存するために作成されます。たとえば、atmel ATTINY4 / 5/6/10チップには、合計6ピン、電源用に2ピン、リセット用に1ピン、汎用ピンが3つしかありません。命令は、独自の3行インターフェースを介して順次送信されます。
マイクロコントローラの定義に応じて、マイクロプロセッサと見なすか、マイクロプロセッサとして動作するようにプログラムすることができます(つまり、1つまたは複数のシーケンシャルバスで専用CPUをシミュレートします)。
この質問は、ある種のデータバスが公開されていることを明確に示していますが、パラレルバスであることは示していません。理論的には、12ラインのデータバスは、1つのシリアルデータラインと11の補助/グランド/ステータスラインで構成できますが、おそらくそれはあまり健全な考えではないでしょう。
実際、プロセッサは、データと同じバスラインで命令を受け入れる必要さえありません。
これは、ALUがマイクロプロセッサの一部ではなくディスクリートチップであったが、現在ではほとんどの場合経済的に実行可能でない場合に容易に起こり得ます。
しかし、命令のためだけの専用線でCPUを実装することを妨げるものは何もありません。このようなCPUは、単一の操作をデータの配列(SIMD)で実行する必要がある場合に役立ちます。
命令バスの幅は完全に任意なので、可能な最大オペコードカウントも同様です。
オペコードの最大数は、実際にはいくつかの方法で考えることができます。
これは、データバス幅ではなく、命令幅から収集できます。通常、オペコードは単一のメモリアクセスに収まり、答えは2 ^ 12です。しかし、プロセッサはマルチサイクルオペコードデコードプロセスを実装して、可能なオペコードの数を2 ^ 12を超えて拡張できます。
プロセッサが直接アドレス指定できる命令(オペコードを含む)の最大数は、アドレスバス幅(2 ^ 16)によって制限されます。ただし、間接的にプロセッサはより多くのメモリをアドレスすることができます。たとえば、オペコードは、ページスワップまたは別のソースから命令をフェッチする同様の操作を容易にすることができます。
あなたはこの質問に混乱するのは正しいです-それは非常にひどく書かれています。
ただし、この質問の目的は、マシンの命令語サイズを決定することだと思います。提供されるデータが非常に不完全な場合、これはデータバスの幅に対応する必要があります。アドレスバスの幅によって、メインメモリの最大サイズが決まります。
実際には、特定のマシンの命令の「オペコード」フィールドは多くの場合、命令自体よりもかなり小さくなりますが、命令はデータバスよりも広い場合があります。
古いMotorola 68008はその典型例です。8ビットデータバスを備えた68000のコスト削減バージョンでしたが、同じ16ビット命令ワードを使用しました。通常、7ビットがオペコードを決定します(残りソースとデスティネーションのレジスタ、およびアドレス指定モードを識別します。これらはすべてopcodeではなくオペランドと見なされる必要があります)。オペコードにアドレッシングモードビットを含めると(一部のように)、合計10ビットのオペコードフィールドが作成されます。一部のアドレッシングモードでは、実際の命令が大幅に長くなる場合があります。