0

I am creating a Primitive Virtual Machine which is kind of inspired by LC-3 VMs but a 32-bit version. I am feeding the machine set of instructions. After executing the first instruction, how will the PC know the location of the second instruction.

Is there a particular method to store the instructions in memory in a systematic way so that PC knows the address of the next instruction

Example - All instructions are stored in a linear way as in memory[0] = instruction1, memory[1] = instruction2 etc.

Thank you for the help.

thevortex_17
  • 13
  • 1
  • 5
  • 2
    What's the difficult part? Your example just shows PC going up by 1 – harold Sep 08 '20 at 10:15
  • 2
    *Is there a particular method to store the instructions in memory in a systematic way* - Yes, instructions are stored in contiguous order of increasing address, like an array. That's why PC can just increment, except on branch instructions. Exactly like you'd loop a pointer over an array to read it sequentially. – Peter Cordes Sep 08 '20 at 10:30
  • No i saw in some website they are incrementing the pc = pc + sizeof(instruction) and then accessing the next instruction. Also, what if the next address contains data and not instruction ? I thought there might be a more systematic way other than example I mentioned above. @harold – thevortex_17 Sep 08 '20 at 12:28
  • If the next address contains "data and not an instruction", that means that data is actually an instruction because it will be executed. 1 vs sizeof(instruction) is an arbitrary choice, it only gets interesting if you had variable-length instructions. – harold Sep 08 '20 at 13:10
  • Why do you say "no"? Stepping through an array of fixed-width elements is exactly what `byte_offset += sizeof(element)` does in C. Or did you get confused by the mix of C and asm ideas, and think `PC += sizeof(instruction)` instead of `instruction *PC;` / `PC+=1` meant PC was incrementing by 4 instructions if each instruction was 4 bytes? In asm, we have to deal with byte offsets, not element offsets, so PC+=sizeof(instruction) means advance by 1 instruction in asm terms. If you had a variable-length instruction set like x86, that still works: start decoding the next after the end of prev – Peter Cordes Sep 09 '20 at 09:29

1 Answers1

2

It depends on whether your Processor architecture is RISC or CISC. In the context you asked, A CISC processor has instructions whose size vary, say from 1 to 14 bytes, like for Intel processors. If it is RISC, each instruction size is fixed, say 4 byte, like for ARM processors. All the instruction of a program are stored, in sequence, in main memory. It is the processor control unit that decides how much to increment the PC. Instructions from the main memory would be read in sequence.

So say in CISC architecture, a single 8 byte read from main memory, can contain up to 8 '1 byte' instructions, e.g., repetitive 'inc ax' instruction in Intel processors. After sending the first instruction for decode, the control unit will increment PC by 1. But, at other extreme, there could be a instruction like 'add REG , [BASE+INDEX+OFFSET]' , which can take 13 bytes to store all the information (opcode + REG id + base address + index + some offset) that is there in the instruction. For such instruction, two memory read operation would be required to fetch the full instruction. After sending it for decode, the control unit will increment the PC by 13.

For RISC it is simple. Increment PC by size (2,4,...) of instructions.

Only exception is when there is branch. In that case, PC value is reset at usually the execute stage.

Instructions and data are generally grouped (segmented in some processor architecture) and stored separately. A code segment will end with some kind of return or exit instruction. If PC is set to some memory address where data is stored, the control unit of the processor will process it as instruction. After all both data and instructions are nothing but a sequence of bits! The control unit will not be able to differentiate. It is usually the role of OS or programmer (if there is no OS, like on micro-controllers) to prevent such anomaly.

ajit
  • 410
  • 3
  • 9