|
Volume Number: | 1 | |
Issue Number: | 1 | |
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 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.
- SPREAD THE WORD:
- Slashdot
- Digg
- Del.icio.us
- Newsvine