Modeling Memory
Modeling Memory in CS 5: Von Neumann Architecture
In CS 5, our model of a computer (the Harvey Mudd Miniature Machine, or Hmmm) looked like
The Central Processing Unit (CPU) is where all of the computations take place. There's a small number of registers that are close to the CPU and, consequently, very fast to access. The rest of the memory is in the stack. It's farther away, and slower; to be able to use a value on the stack in an addition, for example, we have to first copy it into one of the registers.
Some registers had special jobs. We had one that held the result from a function call, one that kept track of which Hmmm line to return to at the end of a function, and one that kept track of how much of the stack we'd used.
In CS 5, our goal was to help you get a sense that the way computers work doesn't involve magic. Each of the pieces of how it works is understandable. The model we used matched the von Neumann Architecture that most modern computers use.
But we made some assumptions to simplify our model. For example, Hmmm could only work with integers. But we know that “real” programming languages such as C++, Python, and Java can have different types of variables, and that different types of objects take up different amounts of space!
Modeling Memory in CS 70
In CS 70, our goal is to model the correctness of C++ code. That means we'll abstract away some of the details of the von Neumann architecture that we've found get in the way of modeling correctness.
We won't have any registers at all: different computers have different numbers of registers, and the correctness of our code shouldn't depend on them. As it turns out, some of the things we used registers for in Hmmm (like storing return values and keeping track of which line of the program we were on) are things that we're pretty good at tracing by pointing to our models with our fingers!
We'll recognize in CS 70 that variable type is important, but we won't worry too much about the details of exactly how much space each variable needs. Instead, we'll assume that the slots on the Stack are the right size for whatever type we're expecting them to hold—every value of the same type will always fit in the same-sized slot. For our diagrams, we don't need to delve into details of how a given C++ system determines the right size for a Stack slot of a particular type; we'll just label each slot with its type so that we know what it's supposed to hold.
Just like in CS 5/Hmmm, our local variables will be stored on the stack. And just like in CS 5/Hmmm, the first thing we put on the stack will go in the top slot, and every time we need more space, the stack will grow down.
That means we can now expand our memory model to hold more than one variable. A program with the declarations
int x = 42;
int y = 0;
int z = -70;
would have a memory diagram like
Notice that our first memory location is "S1", indicating that it's the first spot on the Stack. Subsequent spots are named S2, S3, and so forth.
Want to know more about how real computers work?
HMC offers a couple of courses that delve more deeply into the architecture of real computers. Both CS 105 and E 85 are good courses to consider if you'd like to better understand a real computer. They deal with some of the details that we'll abstract away in CS 70.
I hope to see you there!
(When logged in, completion status appears here.)