Von Neumann CPUs

I have a question regarding PCs.

I know that the CPU performs arithmetic operations only on its registers and data stored in RAM has to be fetched beforehand.

However, how does program memory fit in?

I know the Harvard architecture well (it's my job infact) where a separate bus (and indeed memory) is used to store the program.

Where is the program stored in a PC? And how is it loaded to and fro?

 

Log in or Sign up to hide all adverts.

thanks, but I know all about that.

It's the program memory I am specifically asking about, not the data memory.

If in a Von Neumann they're the same thing, then how is the handled?

 

Log in or Sign up to hide all adverts.

in a CPU where the data and program reside in the same memory the scheme is as follows:
there are 2 components that are necessary to keep the program and data seperate, they are the program counter and the op code decoder.
these two components keep the CPU working on the program.
initially the program counter is loaded from rom and is started at the same address every time the CPU is reset or restarted. from then on with every opcode that is decoded the opcode decoder also tells the program counter how many bytes each opcode take up in memory. in the motorola CPU the 6809 the opcodes were 1, or 2 bytes in length. the data bytes that followed the opcode was also 1 or 2 bytes.. this information was decoded along with the other particulars of the machine state with the rest of the opcode and passed on to the program counter, so each time the program was incremented it would be incremented by the correct amount. if for some reason the programmer left off a byte or included a byte the the program counter would get out of sync with the program and the CPU would crash.

 

Log in or Sign up to hide all adverts.

Ah, I had wondered how variable-length instructions worked!

I guess the CPU just 'loads' the program from RAM to registers as if it were just any other data. Come to think of - this must be the case as overflow exploits rely on program data being mixed with functional data.

I guess Harvards are therefore immune to overflow exploits as return pointers can't be redirected to point at data registers?

 

technically the opcodes, which are the program, are loaded into the opcode decoder. the data part can be treated like any other number or it can reference a memory location such as STO &hfefe or BRA &hfa. in the first case the number fefe is the actual location, in the second the number is relative and backwards to the program counter. in both cases the numbers are in hex. the &h part is specific to tandy to denote hex numbers. (tandy uses the 6809 in some of their computers)
when the CPU is in the fetch state it fetches the opcode, routes it to the decoder to detirmine how many data bytes to fetch, then it fetches the data.
these bytes reside sequentially in memory.
from the beginning of the program to the end each memory location had to have a opcode or data or a NOP.
after the data is fetched the machine switches to the execute cycle where the opcode is executed. the program counter is also incremented during the execute cycle to prepare for the next fetch cycle.

there are also 2 different ways to handle peripheral interrupts.
one is by IN and OUT instructions.
the other is by memory mapped I/O. this type treats a peripheral like any other memory location.

 

yes when I say program naturally I mean the machine code.

From what you've written it looks like the CPUs you're experienced with do the sequence of things mine do (instruction decode, execute).

I was just wondering how opcodes were stored. Obviously they're stored in CPU registers. (Of which there must be loads.... the CPU I'm designing uses only 16 registers!)

 

no.
the opcodes are stored in memory just like the data.
example:
0000 LD &h6700,&h0
0005 INC &h6700
0009 BRA &hfb

the above will crash the machine with an OV error when mem location &h6700 gets to &hff and is incremented again.

there are a few things to note:
one, the bytes reside sequentially in memory, one after another. the opcode INC, and all opcodes for that matter, is a byte like any other.
tw0, the backwards branch at location &ha, all branches i am familiar with branch backwards starting at the current program counter. in this case the program counter is referencing &h0b

what i'm saying here is that the opcodes are referenced from memory by the program counter and sent to the opcode decoder. the decoder determines the state of the machine depending on the opcode.
when one fetch/execute cycle is completed the next opcode is fetched, sent to the opcode decoder, the machine state is set and the instruction is executed..

the program counter ( from now on referenced as PC) fetches the first one or two bytes. it is assumed these bytes are opcodes. they are sent to the decoder to set the machine state.

the PC and opcode decoder are the only registers required to execute a program. of course other registers are needed to do anything meaningful other than incrementing a location such as an ALU to add, and various other registers to hold temporary results.

the PC fetches the opcode, the opcode is routed to the decoder to set the machine state and the PC is incremented for the next fetch cycle

 

total understanding has been achieved!

Harvard is the way forward

Please Register or Log in to view the hidden image!