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 aud 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 02, 1996 07:13 PM by M. Smith.
Copyright -- M. R. Smith