|
|
|
|
Can I clarify what the "Memory Address Space" section of this page is saying?
Firstly I am confused as to why a 16 bit system uses a 15 bit address space; I thought a system of 16 bit is a 16 bit system because it's addressing is 16 bits, not 15!?
Secondly it states that Instruction Memory is read only. So am I correct in thinking this means that the CPU has a set of fundamental instructions (programs) that it can do and this is set at time of manufacture using a ROM chip. These instructions become the cpu's "instruction set" which the programmer can then use to construct their programs?
Thanks,
NAND
|
|
Administrator
|
Although there is no universal definition, it is generally the case that an n-bit system has a data path that is n-bits wide. The address bus width is a completely different matter that, out of convenience, is often the same or similar. The original PCs were based on the 8088 that had an 8-bit external data path, a 16-bit internal data path, and a 20 bit address bus.
The addressable memory space of the Hack platform is a reflection of the fact that address values are often encoded in the instructions and, for the Hack, this means in the A-type instructions. A-type instructions can only load 15-bit values. So accessing anything above 15-bits would require some kind of gymnastics and while this is certainly doable, it is not necessary in order to accomplish the goals of the course. So the platform only implements memory that can be directly accessible via A-type instructions.
The instructions are located in ROM -- but it is a ROM that is loaded with YOUR program when you launch the CPU Emulator. In the real world, you might make that ROM with your program or, if your volume is high enough, you might pay the manufacturer to burn it into the ROM when the chip is manufactured. There are a number of different technologies, both across the decades and also at any particular moment in time, to accommodate various scales of production from one-off prototyping to consumer-scale quantities.
|
|
|
Thank you as always WBahn.
So in real world terms the CPU's intruction memory ISN'T ROM?
I am confused here between instruction set and instructions.
Instruction Set = the capabilities of the CPU and how they are called by the programmer
Instruction Memory = the actual program written by the programmer
Is this correct?
Finally the n-bit systems - does this mean that desktop 32bit vs 64 bit systems ae so called because the have 32bit or 64bit register sizes respectively?
|
|
Administrator
|
Slight_Of_Nand wrote
So in real world terms the CPU's intruction memory ISN'T ROM?
Since we are using a program to emulate the CPU and everything associated with it and that program runs in the host computer's RAM, the Hack ROM is emulated in RAM. But it BEHAVES like ROM as far as our Hack program is concerned because we can only read from it -- we can't change what is there.
I am confused here between instruction set and instructions.
Instruction Set = the capabilities of the CPU and how they are called by the programmer
Instruction Memory = the actual program written by the programmer
Is this correct?
Close, but not quite. The Instruction Set is just that -- a set of instructions that I can choose from when building my program. For instance, I use the instruction
D=D+A
because it is in the Instruction Set. But I can't use
D=M+A
because it isn't.
Instruction Memory is just that -- the memory where the instructions are (ow will be) stored.
The program itself would be referred to as the "program" or the "instructions".
Finally the n-bit systems - does this mean that desktop 32bit vs 64 bit systems ae so called because the have 32bit or 64bit register sizes respectively?
Basically. Keep in mind that a modern desktop processor has around two billion transistors on it and has evolved over a period of nearly half a century, so it is an extremely complex thing that has few easy descriptors.
There are actually a variety of register sizes on such a processor, but if it is a 64-bit processor then the instruction set and the hardware are optimized for working with 64-bits at a time.
|
|
|
Slight_Of_Nand wrote
So in real world terms the CPU's intruction memory ISN'T ROM?
I understand your question a bit differently from WBahn (judging by his answer). My take is as "are real world computers like PCs, Macs, etc. store their programs in ROM or in RAM?"
The answer to that is: mostly in RAM. There are initial programs, which initialize the computer and load the operating system, which are stored in ROM[1]. Most normal programs are stored in and ran from RAM.
But if we go back to the 80s and 90s, a lot of game consoles were using cartridges. These cartridges actually had ROM chips[2], containing the program. This program directly ran from ROM: no installation needed. The RAM was used to store data[3]. This is very similar to how the HACK computer works.
----
[1] Most probably some flash memory, which can actually be updated, but which normally operates like ROM.
[2] Among others. Some games contained additional hardware to enhance the standard capabilities of the console.
[3] There is an important difference between those consoles and a HACK machine: the consoles could run code from the RAM if they needed it. The only thing that were stopping them from doing so was common sense and the scarcity of RAM. This is known as the Von Neumann, architecture or Princeton architecture.
The HACK platform on the other hand implements the so called Harvard architecture, where code and data are separate. Code cannot be read as data, nor data can be executed as code.
I think the authors chose the latter for this project because the CPU can be implemented much easier.
|
|
|
Re 15 bit and 16 git instructions, the book writers decision will make a lot more sense at the end of chapter 6 (or even halfway through it).
This happens a lot in Nand2Tetris, "why on earth ?" followed by "oh I see !" a chapter or two later...
  Further more I think the answer to the second part of your question is, Yes.
(Although I'm not sure which ROM or CPU you're referring too, the one in your machine, or the CPUEmulator that you're maybe using supplied with the course?)
This ping's me for another generalisation about the book, is there is also a lot of extra detail in the course, which isn't always necessary for completing the project at the end of each chapter. Of course once one has successfully completed that project it's then much easier to see what is pertinent and what isn't. I've certainly been confused at various points.. but once you're through it becomes clear..
Lozminda
|
|
|
Indeed.
I am also currently getting tripped up over D Registers, A Registers, Data Memory, Address Memory, Memory Spaces, RAM, etc...
I am making the following assumptions please correct me if wrong:
Memory access = accessing RAM (either data or instructions)
Memory Address Spaces = the 15 bit location of the RAM section we want to use (a 16 bit register or a word)
RAM is made of registers but is refered to as simply memory.
Data memory == Memory == M == RAM
Am I correct?
|
|
Administrator
|
Slight_Of_Nand wrote
Indeed.
I am also currently getting tripped up over D Registers, A Registers, Data Memory, Address Memory, Memory Spaces, RAM, etc...
I am making the following assumptions please correct me if wrong:
Memory access = accessing RAM (either data or instructions)
Memory Address Spaces = the 15 bit location of the RAM section we want to use (a 16 bit register or a word)
RAM is made of registers but is refered to as simply memory.
Data memory == Memory == M == RAM
Am I correct?
To some degree it depends on if you are talking in general terms, or in terms specific to the N2T project.
Don't make things more difficult than they are.
Memory access simply means accessing memory, regardless of what kind of memory it is. Within the context of a specific discussion, it could be more specific. In the context of N2T, it could refer to RAM (if you are talking about accessing data), ROM (if you are talking about accessing instructions), or either (if you are talking about what is happening during a clock cycle in general).
A memory address space is simply a range of address values relevant to the discussion at hand. For instance, the RAM address space of the Hack is from 0 through 24576, so more than 14 bits but less than a full 15 bits (and so 15 bits is required to access it, but not all of those 15 bit addresses are within the space). But we can also talk about subportions of the memory as being an address space. For example, the general purpose RAM space is a full 14 bit space that occupies the bottom half of the overall RAM address space while the screen memory is a full 13-bit address space that is parked at the start of the upper half of the overall space.
The exact meaning of the term 'register' depends on the context of the discussion as well. In some discussion it simply means a memory element of some kind. In other discussions it is restricted to referring to small amount of the highest speed memory in a system that is part of the CPU itself. In the Hack it might refer to just the three CPU registers (A, D, PC), or it might refer to the pseudo registers R0 to R15 (which are pseudo registers solely because of how we choose to think of them and, in part, because we assigned those RAM memory locations specific hard labels). It might also include the so-called M register, which we can get away with because the Hack can access it just like it can access the A register or any of the pseudo registers, so it is convenient to think of it as a register. In most architectures accessing data from a register is very different from accessing data from RAM, and so they are not thought of as being interchangeable.
|
|
Locked
