In a 32 bit processor as I understand, each instruction is 32 bits. So, for the MOV instruction in assembly, how do you only use 32 bits for the op code plus the parameters? So for:
MOV register, [address]
Doesn't the address take up 32 bits by itself? So wouldn't that take up the entire instruction? Maybe I have it all wrong, but I'm trying to implement a VM in C/C++. Help?
x86 instructions have variable length. The CPU starts reading instruction with first byte, identifies the "opcode" then keeps reading following bytes depending on actual instruction.
I stopped debugger (Visual Studio) at random point and its disassembly window has an option "Show Code Bytes" which gives an example of instruction length. Have a look below:
In particular, have a look at line with mov [ebp-15Ch], eax which is close to mentioned in your question. The corresponding bytes include A4 FE FF FF which is 32-bit value for -15Ch.
Actually, opcodes can be variable length or fixed length depending on the architecture. Also there are 16- and 32-bit processors with 20-bit address bus. The architecture bit width is not very clear these days. It's more of historical thing. I guess the best "definition" these days might be the width of a "logical" internal databus. (Remember 8088: 16-bit device with 8-bit multiplexed data bus.)
Some processors, such as x86, solves this problem by having variable length instructions, so instructions are not 32 bits long - x86 have some instructions that are a single byte long, and some instructions are over 10 bytes. (This also means that instructions aren't always aligned on 32-bit boundaries, obviously).
Other processors solve it by "two-part constant loading", for example ARM, MIPS and 29K have instructions that load the "low part" and "high part" as separate entities (typically, the loading low part clears or sign-extends the upper part, and the high part leaves the low part unchanged, that way, small values can be loaded in a single instruction).
Of course, a lot of the time, we're not dealing with constant addresses anyway, but with variables that hold addresses (aka pointers or references), in which case a "load" instruction loads from a an address that is in a register, rather than a constant value.
In assembler like ARMv7 which is strictly 32 bits, you cannot store the op-code and an absolute address in a single instruction. What you have to do is either
The ARM architectural manual can help with this.
There are good answers here explaining instruction format. However none seem to clarify what seems to be your confusion: on a 32 bit architecture the instruction operands are 32 bits in length (*), not the instructions. An instruction is composed of an operation code [and operands] (not all instructions have operands e.g. nop, sti).
(*) this doesn't hold true as a no matter what rule. For instance the 32 bit x86 architecture has a instruction set extension (SSE) that takes 128 and even 256 bits operands.
Risc processors, like arm, have fixed size instructions. X86 is a cisc processor (variable size instructions). In the case of a risc processor, the 32 bit address is split in 2 parts (16 bits - hi and low) and is loaded by executing 2 load instructions into one register and then we can load(mov) the contents of the address in another register. So it can take up to 3 instructions to move something into a register from memory.
The CPU doesn't "communicate" with the OS. A CPU is just circuitry. The instruction-decode circuitry activates other circuits based on pattern-matches against the instruction bits that it read from memory.
They're all standardized so the same OS can run on any x86 CPU, for example.
However, a 32-bit CPU would processing lower of process than a 64-bit CPU. The CPU can be divided into units, then they could be accessed like a memory IC.
So it's still hard to write software for your hardware if you're not supported by a team.
