0

I have been watching Ben eaters breadboard computer videos and have trying to figure out something for a while. When he shows the instructions, he shows an example of a LDA instruction which takes a value stored in RAM and puts it into the A register. I was confused because the LDA instruction has an operand that points to a memory address that has a value. My question is how the program counter later doesn't just execute that value that the LDA instruction points to. I know there are answers to this problem but can never find one that really explains my question. Also the reason I want this is because I am trying to build my own breadboard computer in my free time.

I have had a few ideas but haven’t come up with a solid solution. I looked it up but couldn’t find anything useful.

  • cpu increases program counter multiple times to point to the next instruction after data – Iłya Bursov Feb 17 '23 at 02:04
  • Does this answer your question: https://stackoverflow.com/questions/2022489/how-instructions-are-differentiated-from-data – Moshe Katz Feb 17 '23 at 02:07
  • 2
    Long story short: it does not. From a CPU point of view, memory is memory. Whatever it is stored inside is irrelevant for the CPU as it only sees 1s and 0s. In practice, clever architectures try to keep instructions and data separate by assigning different memory positions. Ultimately, if the CPU loads a memory position as an instruction it will very well try to run it (fun fact it will, in most of the cases, succeed albeit it will leave the program in a corrupted or unstable status) – carlosV2 Feb 17 '23 at 02:07
  • You'll be wanting to learn some [assembly language](https://developer.arm.com/documentation/den0013/d/Introduction-to-Assembly-Language) and how to use it to control a machine instruction set. – O. Jones Feb 17 '23 at 02:09
  • I already know assembly – TheDestroyer15 Feb 17 '23 at 02:41
  • I also have seen many explanations like the one by carlosV2 but I think I might need it explained in a different form – TheDestroyer15 Feb 17 '23 at 02:45
  • Code fetch uses different circuitry than data load/store. Or in a simplistic CPU like Ben Eater's (no caches, one shared memory bus) the logic driving the memory bus has also selected what to do with the byte when it arrives: treat it as data or an instruction, sending it to decode circuitry or to a register. – Peter Cordes Feb 17 '23 at 02:56
  • Does ben eater mention anything related to this in any of his videos? – TheDestroyer15 Feb 17 '23 at 02:59
  • Oh and also I don’t want 2 different memory spots 1 for data and 1 for instructions. I just want one to store everything like the way ben eater did it – TheDestroyer15 Feb 17 '23 at 03:27
  • How about this then: take the instruction for x86 architecture `mov ax, 0x10`. If you compile this instruction to byte code, you will see it is `66 b8 10 00`. This, however, could be just the numbers `47206` and `16` which could just be two numbers to be added by the CPU (data). So, what is the difference between `mov ax, 0x10` and the numbers `47206` and `16`? None. They are just a bunch of 1s and 0s. It's the interpretation that you do about those 1s and 0s what matters. If you think those numbers are an instruction, so be it. Otherwise, if you think they are operands, they can very well be. – carlosV2 Feb 17 '23 at 15:46
  • Hmm. I see what you mean but it doesn’t fully anwser my question. I guess a better way of saying I would be how do you make sure data dosen’t accidentally get loaded as an instruction. – TheDestroyer15 Feb 17 '23 at 21:04
  • Like I said, by designing the CPUs internal logic to not be buggy, to have the control signals set appropriately when a byte is arriving from memory so it goes to a register or the ALU if it's data, or to the decoder if it's from a code fetch. Modern CPUs with split caches want to be doing both in parallel which pushes the problem out to competing for access for L2 cache, but with only one memory interface you need a memory bus interface that can be used by code code-fetch and data load/store parts of the CPU, but not both at once. Control signals control muxes to make this happen. – Peter Cordes Feb 17 '23 at 23:13
  • That explains a lot thank you. I do have one more question. In Ben eaters video he makes a program that loads a value into the a register and then adds that to a value and outputs it on his display. The values he loads and adds together are in memory at memory address 14 and 15. The thing I am having trouble understanding is after the values are loaded in the registers, the values are still in memory. So wouldn’t those values later be executed as instructions? – TheDestroyer15 Feb 18 '23 at 04:13
  • If the instruction pointer (IP) ever points onto 14 or 15 then yes, those values will be executed as instructions. The only thing preventing this from happening is the program itself (for example, if the program consists on a loop that never reaches these locations). Hardware wise, nothing will prevent it on its own. – carlosV2 Feb 18 '23 at 14:26
  • So maybe should I halt the program before it gets to those instructions? Also is the instruction pointer the same as the program counter? – TheDestroyer15 Feb 18 '23 at 14:33
  • I saw the videos some time ago but I think the program counter is how he refers to the instruction pointer (IP is how it is called in x86 architectures). I guess you can build circuitry so that if it detects those addresses, it halts the machine but, imho, it is not worth it. For example, if your program loops indefinitely, then it should never reach those locations. Otherwise, if your program has an actual ending, you could build a halting instruction and place it in the end. Honestly, I think you are too worried about a problem that really isn't such a thing nor it happens that often. – carlosV2 Feb 18 '23 at 18:14
  • I guess I didnt realize how much I was worried about this. I guess I’ll put the question in the back of my mind for now and if I run into the problem I’ll probably come back here. Thanks! – TheDestroyer15 Feb 18 '23 at 19:32

0 Answers0