|Column Tag:||Mac Assembler
Introducing the Mac Assembler
By David E. Smith
Introducing the Mac Assembler
Welcome to the Assembly Language Lab. In this column, we will be discussing programming techniques and applications using the Macintosh Assembler, due to be released. With the assembler, Apple has at last provided a complete stand-alone development system for the Macintosh computer.
The Mac assembler was written by Bill Duvall under contract from Apple and is an excellent product. It includes an editor, assembler, linker and debugger in addition to a number of useful utilities for manipulating icons, fonts and resources. All of the Macintosh toolbox and operating system trap calls are fully supported with macros and equate files. This months column is based on the August 29, 1984 pre-release version of the assembler/editor system.
The editor is nicely integrated with the whole system and provides a very flexible tool for examining and modifying any text file, including BASIC, MacWrite and C as well as assembly source files. The editor is fully disk-based, fast, and outputs text files that can be read directly by MacWrite. Of course, it does not provide formatting capability for word processing as MacWrite does, but it is very efficient for source code editing, or for examining any text file; in this regard, it is the closest thing we have to a universal editor on the Macintosh.
A number of text files are created by the editor, as shown in Fig. 1. These are:
.asm Assembler source file input
.files List of source file names
.link Linker input instructions
.job Exec type input file
.R Resource maker input file
Each of these file extensions indicates a different type of text file created by the editor for use with the other development system tools. The .files type is simply a file containing a list of assembly source code file names. This allows a batch of files to be assembled at one time. The .job type is similar to the old EXEC file on the Apple II in that it is a list of assembly and link commands that are executed one after another as if they were selected with the mouse. The .R type file is unique to the Macintosh. This is a text file of resource descriptions that are compiled into a binary format that can be inserted into the system resource file or an application resource. The .link type provides a list of linker instructions to tell the linker how to create a stand-alone application from the relocatable output of the assembler.
The assembler takes text files with the .asm extension and produces relocatable code files with the .rel extension. These files are not runable however. To be runable, they must first be linked together with the linker. Other files created by the assembler include the listing file and an error file. One non-standard feature is the directive .dump that creates a symbol table file from equate files. The purpose of this is to allow a method of compacting the huge library of system equates that Apple has created as part of the Macintosh development effort on the Lisa. These files take up a considerable amount of room. But with the .dump directive, and a utility to pack the symbols file called PackSym, this overhead is greatly reduced.
The linker is the heart of the development system. It is what actually puts together an application program for you. Macintosh files are composed of two sections called a Resource Fork and a Data Fork. The resource part of an application file includes icon and font definitions, window making instructions and the actual binary code of the program itself. The data part of the file is defined by the application program and normally is empty when the program starts up. The linker knows about resource files and how to pack the code into the application resource fork.
A number of important memory considerations involve the linker. Macintosh has a memory manager and segment loader that control where in memory different parts of an application program should be placed. Data structures defined in the source code by use of the DC directive are stored on the application heap along with the program code in segments. Variable storage defined by the DS directive are relocated by the linker and stored in an applcations globals area which is referenced to register A5, as shown in Fig. 2. The start of this applications globals area is set in the linker input instructions with the GLOBALS command.
The linker input file defines the segments in which the program code will be loaded by the linker. After the program is running, the segment manager can then dispose of unused segments. The manner in which the linker input file is put together determines which code files are associated with which segment. The linker also allows precompiled resource files and predefined data files to be linked to the application code as well. This allows all the files, both resource and data, that are required by a program to be linked together into the resource fork and data fork of the application. In this manner, the user sees only a single file on the disk; a file that in actuality is composed of several files. The system file is an example of a single file composed of many parts.
In this months column, we get our feet wet with a program to create a window on the Macintosh. Since our program will call a number of toolbox routines, a few words about macros are in order. The Macintosh assembler uses both a Lisa type of macro and a style unique to the Mac. The Mac style is delimitated by the word MACRO followed by the macro name, and a vertical bar, |, that signifies the end of the macro. Be careful not to confuse this with a number one.
Our first step is to define the trap macros for the toolbox and operating system routines. This is done by setting the toolbox routine name equal to a trap word constant using the DC.W directive. All intructions found in memory that begin with $A are unimplemented instructions that cause the 68000 to trap to a special routine to handle the exception. Apple has taken advantage of this arrangement to extend the 68000 instruction set by a whole series of toolbox routines that are called as a result of this 1010 trap.
THE MAC DOES WINDOWS!
; EXAMPLE ASSEMBLY PROGRAM
; WINDOWS2.5 (MacTech 1-1)
; VERSION 13 OCT 84
; (C) 1984 MacTec by David E. Smith
; Macro subset for Toolbox stuff
MACRO _InitGraf = DC.W $A86E|
MACRO _InitWind =DC.W $A912|
MACRO _NewWindow = DC.W $A913|
MACRO _setport = DC.W $A873|
MACRO _InitFont =DC.W $A8FE|
MACRO _InitMenu =DC.W $A930|
MACRO _InitDialog =DC.W $A97B|
MACRO _TEInit =DC.W $A9CC|
MACRO _Initpack = DC.W $A9E5|
MACRO _FlushEvents = DC.W $A032|
MACRO _InitCursor =DC.W $A850|
MACRO _GetNextEvent =DC.W $A970|
MACRO _FrameRect = DC.W $A8A1|
; DECLARE LABELS EXTERNAL
XDEF START ; required for linker
; LOCAL EQUATES
MouseDown equ 1
AllEvents equ $0000FFFF
; MAIN PROGRAM SEGMENT
DC.B MINE;find start of program
; -- SAVE THE WORLD ------------
START: MOVEM.L D0-D7/A0-A6, -(SP)
MOVE.LA6,(A0) ; local var
MOVE.LA7,4(A0) ; stack ptr
Since a window is a grafport, our first task is to initialize quickdraw. To do this, we must supply a memory location where the quickdraw globals can be stored. In Fig. 3 we see how the quickdraw globals are stored relative to A5, between the application parameters, and the application globals.
; --INITIALIZE ALL MANAGERS--------
; SET UP QUICKDRAW GLOBALS
PEA -4(A5);push qd global ptr
_InitGraf ;init quickdraw global
The quickdraw globals point to the current drawing port, as shown in Fig. 4. From A5, the application globals area is found. Then the pointer to the quickdraw globals, followed by the quickdraw globals themselves. Finally, the first entry in the quickdraw globals is a pointer to the current port defined by the current grafport data structure. The quickdraw globals are defined in Fig. 5. The grafport is described in Inside Macintosh and is too long to be included here.
Our next task is to define the remaining toolbox managers:
;---- SET UP REMAINING MANAGERS --
_InitFont ; init font manager
_InitWind ; init window manager
_InitMenu ; init menu manager
CLR.L -(SP) ; kill the restart
_InitDialog ; init dialog manager
_TEInit ; init text edit (ROM)
MOVE.W #2,-(SP) ; set-up
_Initpack ; init package mgr
There are two types of windows; those defined on the heap, as we are doing here, and those defined as resources, which we will cover next month. The window definition is defined on the heap by the _NewWindow routine, and is not relocatable. Hence, the heap can not be managed as effectively, but our program is small enough for this not to be a problem. Like all toolbox routines, we must imitate the Lisa Pascal calling sequence by pushing the necessary variables on the stack before actually calling the tooblox routine. The first item pushed is always space for any returned value, in this case, the pointer to the new window.
;-- SET UP NEW WINDOW ON HEAP ----
CLR.L -(SP) ;return window ptr
CLR.L -(SP) ;window record ptr.
PEA WBOUNDS ;window rectangle
PEA WINDTITLE ; window title
MOVE.W #$100,-(SP) ; true = visible
MOVE.W #0,-(SP) ; doc type window
MOVE.L #-1,-(SP) ; window in front
MOVE.W #$100,-(SP) ; true=closebox
MOVE.L #0, -(SP) ; reference value
_NewWindow ; make new window
; -- ACTIVATE THIS NEW WINDOW ------
LEA WPOINTER,A0 ; copy window ptr
MOVE.L (SP),(A0) ; to stacksave
_setport ;current window
Now that we have a window on the desktop, we can draw into it. The remaining code sets up the event manager to detect a press of the mouse button. If the button has not been pressed, then we draw something (a box) in our window with a call to the subroutine QDSTUFF. Otherwise, when the button is pushed, we exit back to the finder. Note that the defined box we are drawing is set up as variables with the DS assembly command. These values will be stored in the application globals area where they can be modified dynamically by our program if we wanted to animate the box.
; --EVENT LOOP ------------
MOVE.L #AllEvents,D0 ;all events
_InitCursor ; make cursor the arrow
MOVE #AllEvents,-(SP) ;mask all events
PEAEventRecord ; event record block
_GetNextEvent ;go check the mouse
MOVE (SP)+,D0 ;get event result
CMP#0,D0;if 0 then no event
BEQGetEvent ;loop until it happens
; JUMP TABLE OF EVENT PROCESSING
MOVE What,D0 ;what to do!
CMP#MouseDown,D0 ; button down?
BEQEXIT ;yes so exit...
BSRQDSTUFF;no so draw box
JMP GetEvent ;get next event
; ---------- END OF MAIN --------------
; ---------- QDSTUFF SUBROUTINE ----------
MOVE.W #10, (A0) ;set up top
MOVE.W #30, 2(A0) ;left
MOVE.W #100, 4(A0) ;bottom
MOVE.W #200, 6(A0) ;right
PEA top ;window rectangle
; -- RESTORE THE WORLD --------
EXIT: LEA SAVEREGS,A0 ; get em back
MOVE.L (A0),A6 ; local var
MOVE.L 4(A0),A7;restore stack
; ---- RETURN TO FINDER --------
RTS ; return to finder
; ----LOCAL DATA AREA ----------
SAVEREGS: DCB.L 2,0 ;set save area
WPOINTER: DC.L 0 ;store window pt
WBOUNDS:DC.W 40 ;rectangle
WINDTITLE: DC.B 12 ; title length
DC.B DAVES WINDOW,0
What: DC.W 0; what event
Message: DC.L 0; ptr. to msg
When: DC.L 0
Point: DC.L 0
Modify: DC.W 0
DC.L GetEvent ;null event
DC.L Exit ;mouse down event
DC.L GetEvent ;mouse up
DC.L GetEvent ;key down event
DC.L GetEvent ;key up event
DC.L GetEvent ;auto key
DC.L GetEvent ;update event
DC.L GetEvent ;Disk Event
DC.L GetEvent ;activate event
; -------------- APPLICATION GLOBALS ----------
; ------------ END OF PROGRAM ----------------
This completes our program. A typical Macintosh application follows this style of sitting in an event loop and waiting for something to happen. Join us next month for more from the Assembly Lab.