Discussion:
Lab 3 Input Problems
(too old to reply)
Brandon
2005-11-22 13:55:35 UTC
Permalink
I have the entire lab written and hopefully functional, but my ta 2
instruction is not working correctly the second time around. That is, when
I first input "1A\n", it works just fine. Then, I use a ta 5 to get the
integer to be stored at 1a, and that works fine. Now I go back to my hex_in
subroutine, but when ta 2 comes around, instead of accepting a character
from the user, a 0xA or "\n" is automatically loaded into %r8. I have
physically traced through the program up to this point and have seen this
happen. Is this a result of using the subsequent ta commands, or perhaps a
consequence of pressing the return key when entering the integer during the
ta 5 instruction?

For now, I will physically program the SAM instructions hardwired into my
program in order to test everything else, but I'm guessing there has to be
something strange going on. Any help or explanation would be greatly
appreciated.
James M. Weber
2005-11-22 14:35:27 UTC
Permalink
I don't believe you should use a "ta 5" at all. I understood that the
user would input both memory and the instructions or data at that memory
location as hex an thus both user inputs need to be received by a
hex_in.

-----Original Message-----
From: ***@d60-65-252-217.col.wideopenwest.com
[mailto:***@d60-65-252-217.col.wideopenwest.com] On Behalf Of
Brandon
Posted At: Tuesday, November 22, 2005 8:56 AM
Posted To: cis.course.cis360
Conversation: Lab 3 Input Problems
Subject: Lab 3 Input Problems

I have the entire lab written and hopefully functional, but my ta 2
instruction is not working correctly the second time around. That is,
when
I first input "1A\n", it works just fine. Then, I use a ta 5 to get the

integer to be stored at 1a, and that works fine. Now I go back to my
hex_in
subroutine, but when ta 2 comes around, instead of accepting a character

from the user, a 0xA or "\n" is automatically loaded into %r8. I have
physically traced through the program up to this point and have seen
this
happen. Is this a result of using the subsequent ta commands, or
perhaps a
consequence of pressing the return key when entering the integer during
the
ta 5 instruction?

For now, I will physically program the SAM instructions hardwired into
my
program in order to test everything else, but I'm guessing there has to
be
something strange going on. Any help or explanation would be greatly
appreciated.
Brandon
2005-11-22 15:13:29 UTC
Permalink
Ahh, right you are. That makes much more sense now, and as long as no SAM
command is entered with a 1 in the 32nd digit, I shouldn't even have to
change anything . Judging from the statements about not giving the program
data that it shouldn't have, this shouldn't be a problem.

Yep... fixed that one thing and now everything runs smooth. It is a little
strange, though, that ta 2 and ta 5 cannot be used together. I mean, that
couldn't have been used in this lab, anyways, but it still seems like
something that is pretty limiting.
Wayne D. Heym
2005-11-22 21:19:29 UTC
Permalink
Post by Brandon
It is a little
strange, though, that ta 2 and ta 5 cannot be used together.
They can be. One must just use an extra "ta 2" to remove the newline
character from the input buffer, the one that "ta 5" apparently leaves
behind.
--
Wayne
Loading...