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 webpages. 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. OK? Good luck getting the dummy program in tonight, and the *real* program in by Thursday night. Yale Patt