Motorola MVME166IG 用户手册
Entering and Debugging Programs
MVME166IG/D2
4-9
4
Entering and Debugging Programs
There are various ways to enter a user program into system memory for
execution. One way is to create the program using the Memory Modify (MM)
command with the assembler/disassembler option. You enter the program
one source line at a time. After each source line is entered, it is assembled and
the object code is loaded to memory. Refer to the Debugging Package for
Motorola 68K CISC CPUs User’s Manual for complete details of the 166Bug
Assembler/Disassembler.
execution. One way is to create the program using the Memory Modify (MM)
command with the assembler/disassembler option. You enter the program
one source line at a time. After each source line is entered, it is assembled and
the object code is loaded to memory. Refer to the Debugging Package for
Motorola 68K CISC CPUs User’s Manual for complete details of the 166Bug
Assembler/Disassembler.
Another way to enter a program is to download an object file from a host
system. The program must be in S-record format (described in the Debugging
Package for Motorola 68K CISC CPUs User’s Manual) and may have been
assembled or compiled on the host system. Alternately, the program may
have been previously created using the 166Bug MM command as outlined
above and stored to the host using the Dump (DU) command. A
communication link must exist between the host system and the MVME166
port 1. (Hardware configuration details are in the section on Installation and
Startup in Chapter 3.) The file is downloaded from the host to MVME166
memory by the Load (LO) command.
system. The program must be in S-record format (described in the Debugging
Package for Motorola 68K CISC CPUs User’s Manual) and may have been
assembled or compiled on the host system. Alternately, the program may
have been previously created using the 166Bug MM command as outlined
above and stored to the host using the Dump (DU) command. A
communication link must exist between the host system and the MVME166
port 1. (Hardware configuration details are in the section on Installation and
Startup in Chapter 3.) The file is downloaded from the host to MVME166
memory by the Load (LO) command.
Another way is by reading in the program from disk, using one of the disk
commands (BO, BH, IOP). Once the object code has been loaded into
memory, you can set breakpoints if desired and run the code or trace through
it.
commands (BO, BH, IOP). Once the object code has been loaded into
memory, you can set breakpoints if desired and run the code or trace through
it.
Yet another way is via the network, using one of the network disk commands
(NBO, NBH, NIOP).
(NBO, NBH, NIOP).
Calling System Utilities from User Programs
A convenient way of doing character input/output and many other useful
operations has been provided so that you do not have to write these routines
into the target code. You can access various 166Bug routines via one of the
MC68040 TRAP instructions, using vector #15. Refer to the Debugging Package
for Motorola 68K CISC CPUs User’s Manual for details on the various TRAP #15
utilities available and how to invoke them from within a user program.
operations has been provided so that you do not have to write these routines
into the target code. You can access various 166Bug routines via one of the
MC68040 TRAP instructions, using vector #15. Refer to the Debugging Package
for Motorola 68K CISC CPUs User’s Manual for details on the various TRAP #15
utilities available and how to invoke them from within a user program.
Preserving the Debugger Operating Environment
This section explains how to avoid contaminating the operating environment
of the debugger. 166Bug uses certain of the MVME166 onboard resources and
also offboard system memory to contain temporary variables, exception
vectors, etc. If you disturb resources upon which 166Bug depends, then the
debugger may function unreliably or not at all.
of the debugger. 166Bug uses certain of the MVME166 onboard resources and
also offboard system memory to contain temporary variables, exception
vectors, etc. If you disturb resources upon which 166Bug depends, then the
debugger may function unreliably or not at all.