Avoiding the run-away code problem -- attempt 1
Although there are things to be fixed, it is still possible to
run the "e1v3.out" code in a more controlled,
non-crashing way.
Reset the Source window to mycode
and the PC to 0x1000. This resetting of the windows and
PC can also be made much easier with a few SDS tricks discussed
on the next page.
Double-click
in the space to the left side of memory location 0x1012.
A BREAKPOINT, marked by the small red flag, has been
set. If you now hit GO, you will find that the
simulation no longer "runs-way" but stops at the BREAKPOINT.
You can clear a BREAKPOINT by clicking on its flag.
Running our code in a very controlled way -- attempt 2
Reset the PC to 0x1000 and use the STEP
option from the Toolbar or the Run
option. Activate the STEP option to move through the
code executing one instruction at a time.
As you STEP through the program, examine the value in
the D0 register shown in the Register
window. You should see
- D0 = 0x27F (639), and PC = 0x1006 after the first
instruction has executed and brought in the contents of
memory location A (0x2000 contains 0x27F (639))
- D0 = 0x1A8 (424)and PC = 0x100C after the second
instruction has brought in the contents of memory
location B (0x2002 contains 0xFF29 (-215) and
added it into register D0
- PC = 0x1012 after the third instruction has stored the
value in D0 into memory location 0x7200 (C). If
you bring up a Memory window you can
examine and clear memory location 0x7200 as follows
- In the left most column of the Memory
window type 0x7200 to show this memory
location.
- In the next column enter 0x0 to clear
location 0x7200.
You can now watch this memory location change as the
instructions execute after resetting the simulation. Note
that you can't use the label C in the Memory
window to specify memory location 0x7200 for two reasons
- You did not EXPORT the label C
from your source code.
Even if it had been exported, the Memory
window thinks that "C" is an address
(as in 0xC) not a label. Try examining the memory
associated with exported labels A or mycode inside
the Memory window and see what I
mean. We need more meaningful names for
"labels" (that's fix 24)
NOTE:- The PC (green arrow) always points to
the instruction about to be executed. All the values in
the registers and memory locations correspond to what happened
after the previous instruction was executed. Make sure
that you don't interpret the simulation information the wrong
way.
Generating a final version of our code
We can now go back and fix up our final code file with the
lessons we have learnt
- We need to activate viewing of both "source"
and "assembly" language information during
simulation sessions.
- We need to allow the simulator to automatically find the
start of our code.
- We need to get the simulator to automatically stop at the
end of our code.
- We need to get the simulator to RESET without
the necessity of us resetting values in different SDS
toolkit windows.
- Using meaningful label names means that the SDS toolkit
can find the memory locations without us having to
remember LSDs (Little Stupid Details) such as
memory addresses of the form 0x720 (or was it 0x7200).
- It would also be useful to set up some standard coding
practices for items that commonly cause problems when
writing in assembly code. That way we can concentrate on
the creative part of the coding rather than the trivial
parts that are used frequently.
- It would be useful to be able to edit, assemble,
link, simulate and automatically find errors in source
files all from within the SDS software tool. No more
switching between the SDS tool and a DOS window.
You might like to try and fix these problems before moving on
and finding my suggested solutions to these problems on the next
WEB page.
Last modified: July 12, 1996 08:00 PM by M. Smith.
Copyright -- M. R. Smith