In the future, please put each question in a separate thread. This also lets you use a more meaningful thread title that captures the nature of each question. I know it seems like a pain, but I think you will like the result, particularly if your thread attracts very many responses. As this is a pretty low-volume forum to begin with, it's not worth trying to fix it for this one.
cdrh wrote
Hi I'm back with more questions. For reference the unit and timestamps are in reference to the Coursera course that is offered. I have provided the links, but you'll have to click on the time since it doesn't provide a direct link to the timestamp.
I can't skip to the timestamp -- either Coursera asks if I want to register and join the course or it just gives me the never-ending "I'm thinking" circle chasing itself. It could be me slow satellite connection, too. But I'll have to just make some educated guesses regarding what's in the video.
QUESTION #1
I suspect that what is happening is that they are talking about general kinds of addressing modes and not the Hack specifically. At least in the book, this is a common theme where they start off talking about something in general and then focus down on the N2T-specific situation. I admit that this is not always done seamlessly and sometimes you are left wondering which they are doing in a specific spot.
In general you have three kinds of addressing -- immediate, direct, and indirect.
Immediate addressing means that the value is contained in the instruction itself. The only command in the Hack that supports immediate addressing is the A-instruction. None of the others do. But most assembly languages allow many instructions to have an value (an operand) stored as part of the instruction.
Direct addressing means that the instruction contains the location of the value to be used. The C-instructions in the Hack use direct addressing when you are using the A and/or the D registers.
Indirect addressing means that the instruction tells you where the location of the value to be used can be found. The Hack uses indirect addressing when you are using the M register. Then you say D = M+1, no one can look at that instruction and tell you where to find the value that is going to be used in place of M. That's because that information isn't contained in the instruction directly, only indirectly by way of the value stored in the A register. But where the result of the computation will get stored IS determinable from the instruction since that information is contained directly -- it will get stored in the D register.
To recap:
Immediate -- the command tells you, "Here's the value I want you to use."
Direct -- the command tells you, "The value I want you to use is stored at this memory location."
Indirect -- the command tells you, "You value I want you to use is at the memory location stored at this other memory location."
He says “Sometimes we have direct access to memory” what does that even mean? When would we not have direct access to memory? Moving forward, the picture shows R1 being added into M[200]. I’m assuming that it means the contents/data from R1 are being added to M[200]. Now he says “In which case we're telling the computer to directly address not just the register 1, but also a memory address that we just specified inside the command.” What does the term “directly address” mean? I’m sorry, but some of these terminologies are quite confusing to me because they are used synonymously and nebulously at times. And what are you accessing? The data of that cell or the address of that cell? From my understanding, it seems that "direct addressing" is when you take the data (not the address) from that RAM cell and write its value into the D-register. And "indirect addressing" is you have to read the address of that RAM cell FIRST, and now you can write the its value into the D-register. Am I correct? @ 7:01, unit 4.6 (
https://www.coursera.org/learn/build-a-computer/lecture/svJNd/unit-4-6-hack-programming-part-1), Noam is showing examples of typical operations. I’m confused at RAM[17] = 10. How does the machine acquire the constant 10?
I'm pretty sure that he is NOT talking about the Hack architecture or assembly language specifically here. After all, commands such as R1 = M[200] or RAM[17] = 10 are NOT legal Hack assembly language instructions. But there are plenty of other assembly languages where they (or something comparable) would be.
I thought doing @10 means A = RAM[10], and subsequently makes M = RAM[10], meaning that it’s just the address location. How is it pulling a raw value constant? I'm guessing it's already there from the instruction set of the HACK architecture, but I don't get how it's already there?
You need to step back and relearn what each of the 28 comp instructions do (and don't do) and how each of the dest options work. I think you are missing some key concepts there.
The command @10 stores the value 10 in the A register. Nothing more, nothing less.
If, after storing 10 in the A register, you use D = A, then that stores 10 in the D register. This is an example if using direct addressing for the comp and for the dest.
If, however, you did D = M instead, then what gets stored in D is the value currently stored in RAM[10]. This is an example of using indirect addressing for the comp since the M tells you that the address of the value you want to use can be found in the A register. We are still using direct for the dest.
If you had done M = M+D then we would be using indirect addressing for the first operand of the comp, direct addressing for the second, and indirect for the dest. The net result would that the value stored at RAM[10] would become 10 greater than it was previously.
QUESTION #2
Question about I/O devices. In the lecture, Noam talks about the screen memory map, and he says its designated in the RAM. So when you go out and buy RAM, is there a certain section within the memory that is designated for the screen memory map? Or…. is there is some kind of ROM inside the monitor that has the screen memory map? Then, once you plug it into the motherboard/GPU/computer, it’ll write its screen memory map to the RAM. Which is the correct understanding?
How this is actually done depends entirely on the hardware designer. It is entirely possible to use plan old ordinary RAM chips and simply design a controller that multiplexes it between the CPU and display driver. Depending on the clocking scheme, this can be very easy to do, or require some gymnastics to make sure that the CPU and the display don't try to access the memory at the same time. Since the data needs of the display are often pretty tame on low-end systems like the Hack (8192 words per frame and even at 60 frames per second that's less than half a MHz, so if the CPU is being clocked at the original IBM-PC clock speed of just 4.77 MHz, it only needs the RAM for it's use 10% of the time. Buy using a small FIFO (a data queue that is first-in, first-out), it can grab video data whenever the RAM isn't being used by the CPU and then feed the display from the FIFO.
Another option is to use what is known as "dual port RAM". This memory has two address buses. The first determines what address the data on the data bus will get written to and the second determines what address the data put onto the output bus will come from. Very handy for lots of I/O type applications. Also not particularly cheap, but can still be an attractive option if it simplifies the design sufficiently.
QUESTION #3
You need to provide that feedback to the authors via Coursera's website. It has the tools to report errors or ask questions. I don't know how actively the course is being maintained -- that's always a sticking point with online courses.
Are you sure they aren't saying "hundred thirty" (speaking in round numbers) and it's just sounding to you like "thirteen", perhaps because of their accents?
QUESTION #4
In unit 4.6 @ 9:20 (
https://www.coursera.org/learn/build-a-computer/lecture/svJNd/unit-4-6-hack-programming-part-1) , Noam shows that the program is being stored/written into the instruction memory, the ROM. I’m confused here because I thought you can’t write to the ROM and you can only read from it. So from my understanding, the ROM structure (architecture) is similar to RAM with the difference being RAM has cells that are empty and ROM has cells that pre-loaded with the defined instruction set. My understanding is that the program that Noam showed would be loaded into RAM, and the ROM is basically used as a way for the CPU to translate symbolic to binary. This is definitely a wrong understanding, so please correct me. Does the ROM also include the assembler? Agh…… I’m so lost here.
A lot of confusion manifest in this question -- you really need to step back and go through it again. And don't be surprised if you have to do that several more times. There's a LOT of concepts involved and it's not surprising that you don't get them on the first go. Even people with lots of experience are going to miss some of the fine points that are brought out by this stuff.
The assembly language program is "assembled" into binary machine code (look at one of the .hack files). This is the data that gets loaded into the ROM. You are correct that the ROM is Read Only Memory -- but it is useless if we can't write to it as least once in order to give the user something to read from it. So there is a separate process by which the machine code is programmed into the ROM. On actual chips, this might be a ROM chip that is programmed by an external programmer and then installed onto the board. It might be ROM that is actually located on the CPU chip itself and that we put the chip into a special mode that allows us to "burn" the ROM contents -- the "burn" terminology comes from the days when this was done by walking though the ROM address space, which came from the factory such that it read as all 0's (or all 1's), and then we applied a high enough voltage to one of the pins to physically burn out and destroy a fuse that resulted in that memory cell no reading the other way. This was very much a "get it right the first time" process. Today the technologies have progressed so that what we often still call ROMs (out of habit or because of the way we use it) are actually reprogrammable (usually using some kind of flash technology).
The key thing is that the program running on the Hack is preloaded into the ROM before the program starts and it has no way to change the contents of that memory -- hence it really doesn't matter whether its ROM, RAM, or someone setting switches really fast, the program can't tell the difference between whatever it is and true ROM.
Locked
