|
|
|
|
The CPU.hdl comments includes:
“The D and A in the language specification refer to CPU-resident registers, while M refers to the memory register addressed by A, i.e. to Memory[A]. The inM input holds the value of this register.”
Then it continues:
“If the current instruction needs to write a value to M, the value is placed in outM, the address of the target register is placed in the addressM output, and the writeM control bit is asserted.”
So, first it says inM input holds the value of M[A].
Then it says the value of M is placed in outM.
In the third C instruction (M=D) of CPU.tst, the value 11111 is written to outM. Register inM input was not involved.
How can it be said that the inM input “holds the value of this register”?
Also, it says “(when writing a value to M) the address of the target register is placed in the addressM output”.
From what I’ve seen so far, addressM always contains the A instruction address.
The comment seems to infer that addressM is used only when writing to M.
But if the instruction includes destination = M, the target register is already in addressM, correct?
@1000
M=D
|
|
Administrator
|
gs99 wrote
The CPU.hdl comments includes:
“The D and A in the language specification refer to CPU-resident registers, while M refers to the memory register addressed by A, i.e. to Memory[A]. The inM input holds the value of this register.”
Read this as:
"..., if the instruction so requires, M refers to the memory register addressed by A..."
Then it continues:
“If the current instruction needs to write a value to M, the value is placed in outM, the address of the target register is placed in the addressM output, and the writeM control bit is asserted.”
So, first it says inM input holds the value of M[A].
Then it says the value of M is placed in outM.
Read this as:
“If the current instruction needs to write a value to M, the value it needs to write is placed in outM..."
Also, it says “(when writing a value to M) the address of the target register is placed in the addressM output”.
From what I’ve seen so far, addressM always contains the A instruction address.
This depends on the design of the CPU. Good engineering practice is not to allow random values on signals. The addressM and outM buses should be forced to known benign values, for instance 0, when they are not needed -- when writeM is false or during A-instructions. (Don't worry about this, it's a concept beyond the scope of this course.)
--Mark
|
|
|
My first question was about inM, that you don’t mention.
The CPU.hdl says: “M refers to the memory register addressed by A, i.e. to Memory[A].
The inM input holds the value of this register (M).”
Regarding the last sentence, inM is not involved with the first two times register M is affected in CPU.tst:
The third C instruction (M=D); the value 11111 is written to outM.
In the next C instruction (MD=D-1); the value 11109 is written to outM.
Is outM not the value of register M?
The spec itself says “outM[16], // M value output”
But in those times, inM value is 0.
Therefore, the sentence “The inM input holds the value of this register (M)” was not true.
If the sentence is needed, it could be “The inM input is a source for this register (M)”
What does hold the value of register M, whether it comes from “inM input” or instructions that affect M?
“The outM output holds the value of register (M).” seems to be more accurate.
The spec could say this: “outM[16], // Holds value of M register”
Note: In this script, inM and reset are viewed as inputs external to the CPU chip. Both could be replaced with asm-type instructions that produce the same effects, is that correct? But having them as external apparently leads to next projects.
|
|
Administrator
|
This test is testing the CPU chip in isolation. There is no RAM, hence there is nowhere for the value on outM to be stored. inM is strictly controlled by set instructions in the test script.
The text in the book describes how the CPU works in the context of Computer.hdl; it does not describe how the test program drives the CPU to test it. The purpose of test inputs is to exercise the data and control paths in the CPU and verify their function, not to emulate the CPU running in the Computer.hdl environment.
I suggest that you complete your Computer.hdl if you haven't and move on the the software projects. Learning how to write functional tests for complex parts might make a good chapter 13 project.
--Mark
|
|
|
I’m not working with Computer.hdl yet; still have issues with CPU.
And the absence of RAM is irrelevant to this question.
The only definition of inM in CPU chip comments is:
“The inM input holds the value of this register (M)”.
When the word “hold” refers to another object, it refers to possession.
E.g. “I’m holding the cup.” (I came to possess the cup before I can hold it.)
“The inM input holds the value of register M” implies inM comes to possess the value of register M.
But does that happen? In your hdl, is inM connected to the output of a register?
In my hdl, inM is connected to the input side of a part.
When the ALU computes a value with destination M, what happens?
It says in effect “Here, outM, please hold this value, even though it’s for a brief time period.
And if you ever see RAM, pass the value along.”
Considering what I’ve learned so far, the sentence defining inM is misleading and erroneous.
When I learn Computer.hdl, perhaps I’ll see it another way.
I'll come back to this post later and explain my observations.
|
|
|
If you're just asserting semantics, then yes, you might think of inM and outM as "carrying" values to and from memory.
|
|
Administrator
|
My last post on this subject.
There is no "M" if there is no Computer.hdl. The only things that store data in the CPU are the ARegister, DRegister and PC.
If it makes you happier, read it as "The value on inM is is to be used in place of the ARegister's stored value if the 'a' bit is set in the c-instruction. The output from the ALU is presented on outM. Hardware external to the CPU will sometimes use this value."
--Mark
|
|
Locked
