Another Lab 2 Question

[Brandon]

The way I implemented opcodes was to mov the value from the MDR to the IR.
Then, I used a srl %r4, 5, %r4 to ensure that only the opcode was in the IR.
The addr can still be obtained from the MDR since that value has not yet
been changed. This works perfectly for executing my program, but in
comparing my register values to those that "should" be there, I see it shows
the IR as still holding the entire instruction, instead of just the opcode.
Is there anything wrong with my implementation (will points be taken off?),
and if so, where should I store the opcode while comparing it to the various
recognized SAM opcodes?

[Ryan McNeeley]

Doesn't the example "output" in the Lab 1 always have the IR holding the
entire instruction and not just the opcode?

Post by Brandon
The way I implemented opcodes was to mov the value from the MDR to the IR.
Then, I used a srl %r4, 5, %r4 to ensure that only the opcode was in the
IR. The addr can still be obtained from the MDR since that value has not
yet been changed. This works perfectly for executing my program, but in
comparing my register values to those that "should" be there, I see it
shows the IR as still holding the entire instruction, instead of just the
opcode. Is there anything wrong with my implementation (will points be
taken off?), and if so, where should I store the opcode while comparing it
to the various recognized SAM opcodes?

[Brandon]

Yes, it does, but Lab1 didn't even read the instruction at all, anyways. I
didn't think it was necessary for the IR to hold anything but the opcode,
but if that's what we need to do, I can change my program just to make it
match what the lab shows, even though my lab works anyways.

Post by Ryan McNeeley
Doesn't the example "output" in the Lab 1 always have the IR holding the
entire instruction and not just the opcode?

Post by Brandon
The way I implemented opcodes was to mov the value from the MDR to the
IR. Then, I used a srl %r4, 5, %r4 to ensure that only the opcode was in
the IR. The addr can still be obtained from the MDR since that value has
not yet been changed. This works perfectly for executing my program, but
in comparing my register values to those that "should" be there, I see it
shows the IR as still holding the entire instruction, instead of just the
opcode. Is there anything wrong with my implementation (will points be
taken off?), and if so, where should I store the opcode while comparing
it to the various recognized SAM opcodes?

[Brandon]

Okay... I think I see the answer to this question. Rather than actually
stripping the digits, I should instead use an srlcc operation. I'll try
this out and see how it goes.

Post by Brandon
Yes, it does, but Lab1 didn't even read the instruction at all, anyways. I
didn't think it was necessary for the IR to hold anything but the opcode,
but if that's what we need to do, I can change my program just to make it
match what the lab shows, even though my lab works anyways.

Post by Ryan McNeeley
Doesn't the example "output" in the Lab 1 always have the IR holding the
entire instruction and not just the opcode?

Post by Brandon
The way I implemented opcodes was to mov the value from the MDR to the
IR. Then, I used a srl %r4, 5, %r4 to ensure that only the opcode was in
the IR. The addr can still be obtained from the MDR since that value has
not yet been changed. This works perfectly for executing my program, but
in comparing my register values to those that "should" be there, I see
it shows the IR as still holding the entire instruction, instead of just
the opcode. Is there anything wrong with my implementation (will points
be taken off?), and if so, where should I store the opcode while
comparing it to the various recognized SAM opcodes?

[Ryan McNeeley]

Oh, I see what you are saying (sorry by the way, I meant to say Lab 2). You
are saying that when you shift your instruction, that your code outputs only
the opcode in the IR place instead of the full instruction as is shown in
the Lab, couldn't you just do a copy of the MDR to the IR again after you
have decoded the opcode as an easy fix?

Post by Brandon
Yes, it does, but Lab1 didn't even read the instruction at all, anyways. I
didn't think it was necessary for the IR to hold anything but the opcode,
but if that's what we need to do, I can change my program just to make it
match what the lab shows, even though my lab works anyways.

Post by Ryan McNeeley
Doesn't the example "output" in the Lab 1 always have the IR holding the
entire instruction and not just the opcode?

Post by Brandon
The way I implemented opcodes was to mov the value from the MDR to the
IR. Then, I used a srl %r4, 5, %r4 to ensure that only the opcode was in
the IR. The addr can still be obtained from the MDR since that value has
not yet been changed. This works perfectly for executing my program, but
in comparing my register values to those that "should" be there, I see
it shows the IR as still holding the entire instruction, instead of just
the opcode. Is there anything wrong with my implementation (will points
be taken off?), and if so, where should I store the opcode while
comparing it to the various recognized SAM opcodes?

[Brandon]

Okay, the srlcc operation didn't work... obviously, since there isn't one.
Instead, I did what I was before, except stored the opcode in %r8 since it
isn't used for a while. I know this is not technically a SAM register, but
I hope this is okay in the sense that I am using %r8 as the "Decoder".

As for your suggestion, I had considered that myself, but figured that was
not in the spirit of the SAM machine, and was merely a work-around.
Besides, with what I had already, it was simple to merely change the %r4's
in my cmp statements instead to %r8's, without having to add new commands
and restructure some sections of code.

Post by Ryan McNeeley
Oh, I see what you are saying (sorry by the way, I meant to say Lab 2).
You are saying that when you shift your instruction, that your code
outputs only the opcode in the IR place instead of the full instruction as
is shown in the Lab, couldn't you just do a copy of the MDR to the IR
again after you have decoded the opcode as an easy fix?

[Wayne D. Heym]

Instead, I did what I did before, except stored the opcode in %r8 since it
isn't used for a while. I know this is not technically a SAM register, but
I hope this is okay in the sense that I am using %r8 as the "Decoder".

A nice solution. I"m glad that you ended up in this place; you've made
a good decision. There's nothing wrong with using %r8 as the
"Decoder". Another possibility here might have been %r1, do you think?

[Deepak Bal]

I used %r1 as a spare register...i think were allowed to do that

Post by Brandon
Okay, the srlcc operation didn't work... obviously, since there isn't one.
Instead, I did what I was before, except stored the opcode in %r8 since it
isn't used for a while. I know this is not technically a SAM register, but
I hope this is okay in the sense that I am using %r8 as the "Decoder".
As for your suggestion, I had considered that myself, but figured that was
not in the spirit of the SAM machine, and was merely a work-around.
Besides, with what I had already, it was simple to merely change the %r4's
in my cmp statements instead to %r8's, without having to add new commands
and restructure some sections of code.

Post by Ryan McNeeley
Oh, I see what you are saying (sorry by the way, I meant to say Lab 2).
You are saying that when you shift your instruction, that your code
outputs only the opcode in the IR place instead of the full instruction as
is shown in the Lab, couldn't you just do a copy of the MDR to the IR
again after you have decoded the opcode as an easy fix?

[Wayne D. Heym]

Instead, I did what I did before, except stored the opcode in %r8 since it
isn't used for a while. I know this is not technically a SAM register, but
I hope this is okay in the sense that I am using %r8 as the "Decoder".

A nice solution. I'm glad that you ended up in this place; you've made
a good decision. There's nothing wrong with using %r8 as the
"Decoder". Another possibility here might have been %r1, do you think?

[Brandon]

Yes, I realized that after I was finished; I had forgotten that we had a
temp register available to us. Thanks for the help.