Today’s topics
Symbolic constants
 Modularization
 Debugging


Quiz #2
Symbolic Constants




May appear in or before the data segment
Equal-Sign (=) Directive
EQU Directive
Notes on constant for upper limit in
Program #2



Use for user instructions
Use for data validation
OK to use = or EQU
Equal-Sign Directive

name = expression
name is called a symbolic constant
 expression is a 32-bit integer (expression or



constant)
Cannot be redefined
Style note:

Use all CAPS for constant names
COUNT = 500
...
mov ecx,COUNT
EQU Directive


Define a symbol as either an integer or
text expression. (Note < > )
Cannot be redefined
PI EQU <3.1416>
PRESS_KEY EQU <"Press any key to continue...",0>
.data
prompt BYTE PRESS_KEY
Calculating the size of a string


Current location in data segment is $
Subtract address of string

difference is the number of bytes
rules1 BYTE
"Enter the lower limit: ",0
SIZE1 = ($ - rules1)
;constant length of rules1 (24)

Constants are treated like labels





Literal value is substituted by assembler
Constants are global
Questions on constants?
More about program development
Modular example (demo2.asm)
Program development
Design
 Implement
 Test / Debug
 Use and maintain

Program Design Using
Modularization

Modularization involves the following:


Decide what your program should do
Set up logical sections



design your program before starting to code
Break large tasks into smaller sections
Implement, test, and debug one section at
a time
Implementing the sections

Lay out the output format
Decide what variables/constants will be required

Define constants



Declare variables (.data section)


Test*/fix (no calculations, usually everything shows 0)
Enter the input code


Test*/fix (syntax check, nothing happens)
Enter the output code


Test*/fix (syntax check, nothing happens)
Test*/fix (no calculations, echo input)
Enter the calculation code

Test*/fix (logic check, verify)
* First try Debug, Start Without Debugging
Modular Development (motivations)

Team environment


Incremental testing


Easier to find errors
Maintenance


Easier to verify (procedures/parameters)
Debugging


Easier to test “sections” as you develop the program
Reliability


Easier to divide the work and assign tasks
Easier to make changes
Re-usable code

Easier to use library modules (don’t re-invent)
Debugging MASM in Visual C++


Set breakpoints by clicking in the left
margin
“Debug”, “Start Debugging”


“Debug”, “Windows”, “Registers”


Execution will pause at first breakpoint
To view register contents
Use F10 (for now) to execute one
instruction


Watch register contents
Changes in red
Debugging MASM in Visual C++



Helps to locate logic errors
Helps to really understand what the MASM
statements do
Hints:




Don’t use F11 to step into Irvine library calls (for now).
You might have to switch back and forth between the
code screen and the I/O screen
If you make changes, remember to “Stop Debugging”
before you restart the modified program
Experiment !!! with other debugging windows, etc.
Visual C++ Debugger

Step Over (F10)





If no breakpoint, starts at first statement in main
Executes next instruction
If instruction is call, executes entire called
procedure
Tip: Use this to step over library procedures!
Step Into (F11)




If no breakpoint, starts at first statement in main
Executes next instruction
If instruction is call, goes to first instruction in
called procedure
Tip: Don’t step into library procedures!
Visual C++ Debugger

Other useful Debug menu items

Before debug session


Start Without Debugging
During debug session
Continue (F5)
 Restart
 Stop Debugging


Others
runs to next breakpoint
Questions?
Program #2 is due Friday
Quiz #2