Tue, 1 Oct 2013, 22:50

A student writes, and brings up a point I thought I made in class, but 
apparently not strongly enough, given some clues in his email:

> Hey Dr.Patt,
> I've written my program and it works but this weird thing keeps popping up
> at the end. I'm unsure how to use the system to halt the processor. I use
> the code:
> 1111 0000 0010 0101; STOP x25 - HALT

Actually, let me interrupt here.  If it says "STOP x25," I would like 
to know the page number, since it should not say that.  It should say 
TRAP x25.  The 16 bit instruction he has at the left is correct.

> Is this correct? I just got it from the appendix in the book. 

If you got "TRAP x25" rather than "STOP x25" in the appendix, then
we agree. Yes, that is correct.

I am interested in knowing why he did not get this from class last
Wednesday, and I repeated it on Monday.  I will not call him out here, but
I would like him to send me email letting me know if he was in class on
Monday or the previous Wednesday.

Recall in class, I said there are certain things the typical programmer
will not do for himself/herself but will ask the operating system for help.
Stopping the computer is one of them.  The programmer gets the operating
system to do his/her bidding with the TRAP instruction.  Some people call
it SYSTEM CALL.  In fact I gave it some silly acronym which I don't even
remember now.  But it is probably in your notes!  In the LC-3, the opcode 
is 1111, and the low 8 bits specify the task the programmer wants the 
operating system to do on behalf of the program.  We call those low 8 bits 
a "trapvector."  The trapvector x25 is a request for the operating system
to halt the machine.

The first program we wrote in class consisted of 6 instructions.  The last
one was 1111000000100101 (i.e., TRAP x25).  It was a request of the operating
system to halt the computer.

> I've attached
> a picture to show you what happens, and another as proof that the program
> can count the "01" occurrences. I don't even use R1 or R7 but numbers pop
> up there at the end anyways. I ran into this problem as I finished just
> now. I would go to TA hours but I'm completely booked for tomorrow and I
> suspect that Thursday's TA hours will be overcrowded with people who have
> procrastinated and I won't be able to ask for any 1 on 1 advice/help :/
> Thank you for your time!
> Best,
> <name withheld to protect the student who noticed numbers pop up in R1 and R7>

My main reason for sharing this with you is to explain what the student
refers to as the weirdness of numbers popping up in R1 and R7.  I thought 
I already had, but apprently I did not.  So, I thank this student for 
giving me this opportunity.  (I still would like to know why he did not
see the TRAP x25 instruction in the first example we worked, but let's leave
that for now.)

Again, TRAP x25 asks the operating system to stop the machine for you.  
The operating system executes a number of instructions to do the job.  
In executing these instructions, values are manipulated, using the registers 
to do these manipulations.  Therefore, the weirdness.

In order to test the machine after your program runs AND before you ask
the operating system to stop the machine, set a breakpoint at the address
of the location containing the TRAP x25 instruction.  You recall your TA
showing you how to set breakpoints in discussion section on Friday.  You
can also checkout the tutorial intro to the simulator which is in the EE306

If you set the breakpoint at that address, your program will run to completion,
except before you ask for the operating system's help, the breakpoint will 
stop the machine.  You can then look in all the registers, memory locations, 
etc. to be sure  your program executed correctly.


Good luck getting the dummy program in tonight, and the *real* program in by
Thursday night.

Yale Patt