Wed, 12 Oct 2011, 01:54

I realize this is a little too late for the first lab, but since it is
so fundamental to your understanding of the computing environment you are
using, I am responding to all of you. 

> Professor Patt,
> 
> Are you and the TAs going to put breakpoints into our program or are we
> supposed to use that command. My last command is the HALT x25 instruction
> but I didn't know about the breakpoint.
> 
> Thanks so much,
> <<name withheld to protect the student who does not understand breakpoints>>

There is no such thing as "putting breakpoints INTO your program."

Programs consist of instructions from the ISA of the LC-3.  Each instruction
is made up of 16 bits, contains a 4-bit opcode, leaving 12 bits for specifying 
the operands.  The complete set of instructions is on the inside cover of your 
textbook. You will note that nowhere does it talk about breakpoints.

Then what is a breakpoint?

The ability to set "Breakpoints" is one of the features of the LC-3 
Simulator/Debugger.  

Suppose you wrote a program that consisted of 32 lines of code, loaded 
into locations x3000 to x301F.  Suppose, for purposes of testing (or
debugging) your program, you wanted to execute the first 20 instructions
of your program, and then examine what is in R3.  Assume there are no 
control instructions in your program.  

You could single-step your program 20 times.  That could get tiring after
awhile, since you only need to stop the program after the 20th instruction
(i.e., the instruction in x3013) is executed.  OR, you could set a breakpoint
at location x3014.  If you set a breakpoint at x3014, the Simulator will
execute instructions one by one, performing the Fetch, Decode, etc. 
instruction cycle again and again, until it reaches the point where the 
Fetch phase is ready to fetch the instruction at memory location x3014.  
At that point, the Simulator will stop, and you can examine the contents 
of any register or memory location.  This is much more convenient than 
single stepping the Simulator 20 times.  It is a very convenient tool for 
debugging your program.

Another example: Suppose you have a loop in your program (most programs do!)
and you want to check certain values at the end of each iteration.  A simple
way to do that is to set a breakpoint at the address of the unconditional 
branch BRnzp that takes you back to the test in front of the loop body.  The
computer executes the test, then the loop body, until it reaches the BRnzp
instruction which is in the memory location specified by the breakpoint. Then
the Simulator stops so you can check the contents of registers and memory.
If you proceed to run again (without disabling the breakpoint), the Simulator 
will execute the BRnzp, then the test, then the loop body again, until it 
reaches the BRnzp instruction again, at which point the breakpoint will cause 
the Simulator to stop.  In this way, you can easily test the results produced 
by each iteration of the loop without having to single-step your program.

As you debug more and more complicated programs, you will find breakpoints 
more and more useful.

Breakpoints are not a part of the program.  They are a feature of the
Simulator/Debugger.  They are like the commands that allow you to examine
values in registers and memory and also initialize values in registers and
memory for the purpose of testing or debugging your program.

I hope the above is clear.  If not, please feel free to ask me or one of the
TAs to explain it further.

I also hope you succeeded with Lab 1.  If not, don't be discouraged.  
Some students do not click with programming right away, and take a little 
time to get used to it.  Most do get it if they continue to work at it. 
Good luck with Lab 2.

Yale Patt