Easy68k+beginners+guide+-+eee3231 18h3

toolbar button is chosen; an editor window titled “untitled .x68” pops up with the contents of file “template.NEW” preloaded. An already existing assembly source can be loaded through the “File > Open…” menu item, the Ctrl-O hotkey or the usual toolbar button. (The same can be achieved directly from Windows by double-clicking on the desired .X68-file.) The “File > Save” menu item, the Ctrl-S hotkey or the standard <Save> toolbar button updates the edited file on the disk; with the “File > Save As…” menu item, the file can be saved under a different name.

3.1.4.

Editing a source file

The built-in editor of Edit68K provides the usual editing features familiar from general-purpose editors (e.g., Notepad), including cut/copy/paste through the system clipboard, Undo (only 1 level in Edit68K!), a Find/Replace facility and printing. The most important formatting requirement for a well-written assembly source code is proper tabulation. The assembler accepts any kind of white space between fields, which can be as little as a single Space character; however, a human reader would require that each of the different fields of the assembly source line (see [2]) be tabulated to the same column. Having concluded in Section 3.1.2 that the Fixed Tabs option is the most practical, the only remaining question is, at which tabulator positions the different fields should begin. Since the width of the statement field and even the arguments field are rather consistent (unless both arguments are labels, which is relatively rare), the trade-off is between the length of labels and the length of in-line comments. Section 2.2 of the 68000 Quick Start Guide [2] explains why labels are preferred to be in the same line as the statements; this means that the statements should be

Peter Csaszar – Lawrence Technological University, ECE Department

7

EEE3231 – Microprocessors Lab

EASy68K Beginner’s Guide

sufficiently indented, in order to leave room for reasonably long labels. The following tabulator column recommendation (counted from the beginning of the line) assumes fixed tabs with size 8: o Label: 0 tabs [i.e., the beginning of the line] o Statement: 2 tabs (max. label length: 15 characters) o Arguments: 3 tabs o Comments: 5 tabs (max. argument length: 15 characters) Note: The EASy68K assembler allows white space after any comma (‘,’) character, e.g., between two arguments, or within the value list of the DC assembler directive. This decision is really left up to the programmer; it is not considered bad assembly programming style not to put spaces to the aforementioned positions. Tip: The caret (‘^’) character on the bottom of the editor window helps to identify where a line should end. For the Courier New font, the caret enforces the following total line lengths: • Size 8: 89 characters • Size 10: 79 characters This is more conservative than the printing limitations, therefore typing past the caret is not a big disaster.

3.1.5.

Assembling and running a source file

The completed assembly program can be assembled with the “Project > Assemble Source…” menu item, the F9 hotkey or the (“Play” arrow) toolbar button. Upon successful completion, the “Assembly Status - ” pop-up dialog box offers to execute the program; clicking the “Execute” button will launch Sim68K, the EASy68K suite’s simulator, with the corresponding S-record file and list file loaded. All assembly warnings and errors are displayed in the lower part of the editor window; if the program contained errors, the “Execute” button in the pop-up dialog box is disabled. Further help on the Edit68K’s operation is available from the EASy68K Online Help [4], under “Editor Operation”.

3.2.

Sim68K Simulator

Sim68K is used to execute, and optionally debug, a previously created and assembled 68000 assembly language program. Figure 3 shows the toolbar provided by the Sim68K program. Auto Trace (F10)

Run (F9)

Open

Run To Cursor (^F9)

Trace Into (F7)

Step Over (F8)

Reset Program (^F2)

Pause (F6)

Reload Program (^F3)

Figure 3 - Toolbar of Sim68K These buttons will be referenced in the following discussions.


8


3.2.1.


Launching Sim68K

There are three ways to launch Sim68K: 1. Choose the “Start > Programs > EASy68K > Sim68K” menu item in Windows. In this case, the Simulator opens with a blank environment. 2. Double-click on an already existing S-record file (*.S68); this will launch Sim68K. If a corresponding list file (same name, “.L68” extension) exists in the same directory, it will be loaded into the simulated environment’s source-level debugging field [the large area under the displays]. 3. Upon successful assembly in Edit68K, click the “Execute” button in the “Assembly Status - ” pop-up dialog box. (Since this action produces both an S-record file and a list file, the source-level debugging field will show the lines of the list file, and the Simulator is ready for operation.)

3.2.2.

Loading an S-record file

A 68000 assembly program can be simulated by loading its corresponding S-record file into the Simulator using the “File > Open…” menu item or the toolbar button. Note: If the S-record file is not accompanied by a list file with the same name [but with extension “.L68”], source-level debugging is not possible i.e., the cannot see the trace of execution through highlighted lines of the source. Furthermore, simple breakpoints cannot be placed.

3.2.3.

Running and pausing the simulation

The following commands can be used for simple execution control: • Run – “Run > Run” menu item, F9 hotkey or toolbar button Switches the Simulator to Running Mode and starts program execution. While the program is in Running Mode, the emerging Output Window will display all program output, and prompt for input whenever desired; also, all execution control menu items and toolbar buttons other than Pause are grayed out. • Pause – “Run > Pause” menu item, F6 hotkey or <Pause> toolbar button. Pauses program execution, and switches the Simulator to Paused Mode. All information in the Simulator’s main window (s and the Cycle Counter), as well as the contents of the view windows (see Section 3.2.7) are refreshed. Execution can either resume with the Run command, or continue in Paused Mode with the single step execution commands of Section 3.2.4. Note: The Simulator does not have a Stop command per se; it can only be paused with the possibility to restart. Only the TRAP #15, task code 9 function call (or the STOP #n assembler instruction in certain conditions) can terminate the simulated program; when this happens, all execution buttons become grayed out. A program [terminated or still active] can be restarted using the Reset Program or Reload Program simulator commands (see Section 3.2.6). Tip: A very useful feature suggested by the author of this document was added to the Simulator in version 2.9.8: • Run to Cursor – “Run > Run To Cursor” menu item, Ctrl-F9 hotkey or toolbar button. Runs the program, but automatically pauses it before the instruction under the Execution Cursor. This command offers a breakpoint’s functionality, without the need of placing a permanent breakpoint (see Section 3.2.5). This is a great way to quickly hone in to problematic areas in the program, and continue debugging with single step execution.


9


3.2.4.


Single step execution

When the program is in Paused Mode, it is possible to step through individual instructions using two different commands. • Trace Into – “Run > Trace Into” menu item, F7 hotkey or toolbar button. Executes the instruction under the Execution Cursor; if the instruction is a subroutine call, the execution will descend into the subroutine. • Step Over – “Run > Step Over” menu item, F8 hotkey or <Step Over> toolbar button. Executes the instruction under the Execution Cursor; if the instruction is a subroutine call, the execution will not descend into the subroutine. Warning! Instructions skipped through the commands of Section 3.2.3 will not leave a trace behind in the Execution Log (see Section 3.2.8); only the above two commands will generate an entry, reflecting the execution context ( and/or memory contents) after the steppedthrough instruction completed. Tip: A very useful and extremely spectacular feature was added to the Simulator in version 2.9.1: • Auto Trace – “Run > Auto Trace” menu item, F10 hotkey or toolbar button. Automatically executes a Trace Into command with the time interval defined by “Options > Auto Trace Options… > Auto Trace Interval”. This simulation command is helpful when an execution log entry is required for every instruction. However, it can also be quite educational to see the execution path a program takes, especially to understand the principles behind nested loops, recursive subroutine calls and other nontrivial situations. Furthermore, observing the constantly updating values of contents can help identify the location of certain bugs quickly.

3.2.5.

Breakpoints

If only a certain section of the program exhibits problems, it would be very tedious to reach the desired point through single steps. The EASy68K makes it possible to “cut to the chase” through breakpoints. If a program execution launched with the Run command encounters a breakpoint, the Simulator is switched to Paused Mode, and the commands for single step execution become available. Breakpoints can be toggled by clicking on the colored dot preceding each line of the list file in the Simulator window. Red indicates the presence of a breakpoint; otherwise the color of the dot is green. Tip: Breakpoints can be “hard-wired” into the source code by placing the “*[sim68k]break” string starting from position 1 into the line immediately preceding the line to be breakpointed. (This feature is useful when a certain portion of the code is being tested for an extended period of time; there is no need to place a breakpoint in the Simulator manually over and over again.) Note: Advanced breakpoint conditions can be selected through the “View > Breakpoints” menu item; however this feature is only recommended for advanced s!

3.2.6.

Restarting execution

A terminated program, as well as an active program [in Running or Paused Mode] can reset from the Simulator (although it is not very recommended for active programs). The reset program always starts out in Paused Mode. The following commands are available: • Reset Program – “Run > Reset Program” menu item, Ctrl-F2 hotkey or toolbar button The simulated processor is reset to its initial state. All s are reset to 0, except the Supervisor Stack Pointer (loaded with $01000000 – just above the highest addressable Peter Csaszar – Lawrence Technological University, ECE Department

10



memory position; recall that the “PUSH” stack operation is implemented with the Address Indirect with Predecrement addressing mode), the Status (loaded with $2000 – Trace Mode off, Supervisor Mode on, all interrupts enabled) and the Program Counter (initialized to the address of the label in the loaded program’s END directive). The program is ready to execute from the beginning; however, this command has no effect on the memory contents whatsoever. • Reload Program – “Run > Reload Program” menu item, Ctrl-F3 hotkey or toolbar button Same as Reset Program, but the memory areas defined by a DC or DCB directive are also reinitialized. This command must be used when a program contains any of these directives to define memory contents that will be subsequently overwritten. Note: The Reload Program command will close any execution logging or output logging (see Section 3.2.8) in progress.

3.2.7.

View windows

The Sim68K simulator’s status can be monitored through the following views: • Main window. The top of this window shows the contents of every data and address (including the Stack Pointer [USP] and Supervisory Stack Pointer [SSP]), the Program Counter [PC] and the Status [SR]. Another very useful feature is the Cycle Counter that shows the number of clock cycles executed during the most recent simulation of the given program. Note: A clock cycle represents a full period of square wave on the processors external CLK input. The cycle time can be calculated as T = 1/f, where f is the clock frequency. Therefore, from the clock frequency and the Cycle Counter’s value, a programs running time on a real-life system, can be estimated. Tip: The Cycle Counter can be queried and reset from an assembly program using the appropriate TASK #15 function calls (task codes 31 and 30 respectively, see the EASy68K Online Help [4], under “Simulator I/O > Simulator”). Warning! The Cycle Counter wraps around after 232 (a tad more than 4 billion) cycles, which takes approximately three minutes on a Pentium 4 processor running at 4 GHz; for long-running programs, the Cycle Counter’s contents are meaningless. • Memory View. This window shows the contents of the entire 16 MByte simulated memory space. Use the navigation arrows or enter an address in the “Address” field to reach the memory area to be monitored. It is possible to change the contents of individual memory bytes run-time, for different debugging purposes. Data can be given as hexadecimal digits (left pane) or as printable ASCII characters (right pane). It is also possible in this window to manipulate entire blocks of memory. The following parameters are required in the text fields: o Copy – Copies “Bytes:” number of bytes from address “From:” to address “To:”. If the two blocks overlap, the destination block must begin at a lower address. o Fill – Fills up the memory area from address “From:” to address “To:” (inclusive) with the 4-byte pattern specified in “Bytes:”. • Stack View. The contents of the stack are shown, broken down as longword values. The current location of the ruling stack pointer (USP vs. SSP) is marked with a different background color. Another marker can be associated with any of the address s; this feature is very helpful to the contents of a stack frame arrangement.


11


•

3.2.8.


Hardware View. A great addition to the views of Sim68K from version 3.0 is the Hardware View window that implements the simulation of certain common hardware features. These are: o Input-output devices. Associated with a unique memory peripheral address beginning at $E00000, these devices implement 8 pushbutton inputs, toggle switch inputs, LED outputs (8 bits in a byte), plus an 8-digit 7-segment display output (8 bytes, with bitmapped segment data in each byte). o Interrupt buttons. These 7 pushbuttons can simulate an autovector hardware interrupt event. It is also possible to associate one of these interrupt signals with the Auto-Interrupt Timer, with a firing period defined as a multiple of 100 milliseconds. This latter feature provides a way to simulate timer-triggered interrupts, a very common technique in microcontroller environments. o Reset button. This button simulates a processor Hardware Reset event. Note: This simulated hardware reset must not be confused with the Reset Program simulator command. When a Hardware Reset event occurs, the SSP and PC s are loaded from the first two entries of the processor’s simulated Exception Vector Table respectively, and the SR is loaded with the value $2700 (only the non-maskable interrupt is enabled); this is the exact procedure a real 68000 processor follows as a response to a hardware reset. Warning! At the time of this writing, the Simulator (v3.4) responds to the Interrupt and Reset buttons, even if the simulation of exceptions is not enabled (see Section 3.2.9). Avoid tampering with these buttons if the corresponding Exception Vector Table entries have not been set up properly. More information about the Hardware View Window can be found in the EASy68K Online Help [4], under the “Simulator Operation > Hardware Window” entry.

Logging

The Simulator provides two different logging facilities. 1. Execution logging. It is possible to save the status of the Simulator into a logfile during execution, by selecting one of the Execution Log type options from the dialog accessed through the “Options > Log Output…” menu item. This information includes the executed instruction, the contents of all 68000 s, and since version 2.2 – thank to the suggestion from the author of this document – also the contents of a selected memory area, after an instruction was stepped through with one of the single step execution commands in Paused Mode (see Section 3.2.4). Note: that when memory logging is also requested as part of the Execution Log, the starting address and number of logged bytes must be provided in hexadecimal. Warning! As it has been mentioned previously, the running commands of Section 3.2.3 produce no Execution Log. Zooming through the entire program containing no breakpoints with the Run command will write nothing in the Execution Logfile! 2. Output logging. By turning on the output logging feature of the Simulator from the “Options > Log Output…” menu item’s dialog, all characters displayed in the output window will be saved in the output logfile. This also includes the characters entered through input (unlike the “>” redirection operator in Unix and DOS), which makes this facility perfect for recording the input/output events of a simulation session. The default logfile names are derived from the name of the assembly source file, but can be changed freely. The logging features are generally very intuitive. However, further information is provided in the EASy68K Online Help [4], under the “Simulator Operation > Options” entry. Peter Csaszar – Lawrence Technological University, ECE Department

12


3.2.9.


Simulating exceptions

As one of the very exquisite features of the Simulator, it implements the simulation of almost all exceptions existing on a real 68000 processor; this also includes hardware exceptions, courtesy of the features provided by the Hardware View window. In order for the Simulator to simulate all exceptions exactly the way a 68000 does, the simulation of exceptions must be enabled through the “Options > Enable Exceptions” menu item. (A checkmark next to the menu item indicates enabled exception simulation.) Tip: When the simulation of exceptions is enabled, the Simulator responds to an exception event by saving the processor’s execution context on the stack (see [3], chapter 4), and fetching the address of the execution handler from the appropriate entry of the Exception Vector Table. Obviously, in order for this to work, the vector table entry needs to have been set up properly, otherwise the simulation goes haywire. This would be very confusing for beginners, who know little about exception handling, and the Simulator’s strange response to uninitialized exception vectors would leave them puzzled. This is why it is possible to disable exception simulation in Sim68K; in this case the occurrence of an exception immediately stops the simulation, with the given exception printed in the status field (bottom portion) of the Simulator’s Main window.

3.2.10.

Using the TRAP #15 Simulator Function Calls

In many computer systems, designers utilize the software exception (a.k.a. software interrupt) feature—available on many microprocessors—for accessing services provided by the computer’s operating system. On the 68000, the TRAP # software exception instruction is particularly suitable for this purpose, as it also switches the processor to Supervisor Mode (see [3], chapter 4), which is in line with the philosophy promoting the separation of operating system code from code through privilege levels. The design of the EASy68K simulator follows this paradigm, and dedicates the TRAP #15 instruction for a special purpose: instead of ing it through the usual exception handling simulation procedure (see Section 3.2.9), it hijacks this instruction, and uses it to access the simulated computer’s “operating system.” This pretended operating system turns the host computer’s peripherals into the simulated computer’s peripherals, and implements a variety of commands (referred to as function calls) including text input/output, file handling, graphics and even sound. These function calls, all “hooked up” to the confiscated TRAP #15 software exception, share a common structure shown below. (Not all steps occur for every function call.) 1. Input parameters are required in one or more of s A1 (string parameter), or D1, D2, D3 and D4 (numeric or character parameter, with the appropriate data type). 2. The unique task code of the function call is required in D0.L. Tip: At the time of this writing, all task codes ed by the Simulator (v3.4) fall within the range of positive signed bytes (0…+127); therefore the MOVEQ instruction is particularly suitable for loading the task code into D0.L. 3. The function call is invoked using the TRAP #15 instruction. 4. Result (numeric or character) is returned in D1 (standard) or D2 (typically if the function call required an input parameter in D1). Warning! Recognize that even for the string input function call (task code: 2), A1 is not an output parameter, but an input parameter instead. This is due to the fact that this function call requires a sufficiently large buffer preallocated, whose starting address is ed in A1; the input string will be placed into this buffer. Since the function call terminates input after 80 characters, the size of the buffer must be set to least 81 bytes (due to the string-terminating 0-character that is automatically appended to the end of the string).


13



Tip: The most frequently used function calls belong to the group called “Text I/O”; the majority of these use s D1 and/or A1 for ing parameters, and only a few uses D2 as well. Therefore it is recommended to reserve D0, D1 and A1, and refrain from using them for any other purpose than the function calls (except maybe for very short-term temporary data storage), so that no bad surprises or inexplicable bugs will occur during program development. Warning: On a similar note: A7 is the system stack pointer, therefore must be fully reserved in all programs using subroutines and/or exceptions. Note: Keep in mind that the numeric input/output function calls of the Text I/O group use the entire 32 bits of the D1 for data transfer, and regard its contents as a signed longword (with range –2,147,483,648…+2,147,483,647). If the value to be input/output has a different data type, conversion overflow testing or sign extension is required respectively. The complete list and specification of the TRAP #15 function calls can be found in the EASy68K Online Help [4], under the “Simulator I/O” entry. The Text I/O group’s function calls are listed in the “Text/Time/Terminate” subentry.

4. CONCLUSIONS This document introduced the EASy68K Assembly Language Tool, a environment for developing and simulating 68000 assembly code on a PC running Microsoft Windows. The author would like to express his appreciation to Professor Charles Kelly at Monroe County Community College (Monroe, Michigan) for the development and maintenance of the EASy68K suite, a truly remarkable software toolkit for the 68000 microprocessor.

REFERENCES [1] Motorola, Inc.: M68000 8-/16-/32-bit Microprocessors s Manual. (Reprinted by multiple publishers, e.g. Prentice Hall, 1989; Barnes & Noble, 1991.) [2] Peter Csaszar: 68000 Quick Start Guide. (Microprocessors Lab supplementary material.) Lawrence Technological University, 2006. [3] James L. Antonakos: The 68000 Microprocessor. Fifth Edition. Pearson Prentice Hall, 2004. [4] Charles Kelly: EASy68K Assembly Language Tool Online Help. (Edit68K “Help > Help” menu item or Sim68K “Help > Sim68K Help” menu item.)


14

Easy68k+beginners+guide+-+eee3231 18h3

Overview 26281t

More details 6y5l6z

More Documents from "Gani Maulana Ilmianto" 5y3w39

Easy68k+beginners+guide+-+eee3231 18h3

Laporan Tetap Praktikum Karet 2 4q1p12

Design Of Column Footing 32381s

Kumpulan Jurnal Biologi 2x3873

Wacana 4.3 3cb4e

4. Memahami Beton Bertulang 2b1x2h