“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 month’s column is based on the August 29, 1984 pre-release version of the assembler/editor system.

EDITOR

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.

EDITOR FILES

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.

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.

LINKER

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.

GETTING STARTED

In this month’s 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)
  LEA SAVEREGS,A0
  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
_FlushEvents      ;flushed
 
_InitCursor   ; make cursor the arrow
 
GetEvent:

CLR-(SP);returned event 
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 ----------
QDSTUFF:

LEAtop,A0
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
_FrameRect;draw rectangle
RTS

; -- RESTORE THE WORLD --------

EXIT: LEA SAVEREGS,A0   ; get ‘em back
    MOVE.L   (A0),A6 ; local var
    MOVE.L 4(A0),A7;restore stack 
    MOVEM.L (SP)+,D0-D7/A0-A6 
 
; ---- 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 
 DC.W    2
 DC.W    335
 DC.W    508
WINDTITLE:       DC.B    12        ; title length
               DC.B    ‘DAVES WINDOW’,0      

EventRecord:
 
 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
 
EventTable:

 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  ----------
 
top:    DS.W1
left:   DS.W1
bottom: DS.W1
right:  DS.W1

; ------------   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.