Toolbox Calls

By Jörg Langowski

First of all let me apologize for two things. The first one is an error in my article on the floating point routines; you might already have noticed it. Page 14 of MacTech 1-1, column 2, sentence 2, last word should be ELEMS68K instead of FP68K.

Secondly, I omitted something that I promised to you, namely the words for toolbox trap calling from MacForth. Let's quickly make up for this: The word that defines an operating system call is OS.TRAP. The word defined by OS.TRAP will take the address of a parameter block from the stack and put it into register A0, then execute the trap given in the definition. OS traps returns their result in register D0, and the content of this register is saved in the predefined variable IO-RESULT before exiting. As an example you may define a call to the READ function as:

:  A002  OS.TRAP  READ  ;

Calling READ with the address of a file control block on the stack will then read the appropriate number of bytes from a file or volume.

All toolbox routines that are structured like a Pascal procedure expect their parameters on the stack in the order in which they appear in the Pascal definition in the Inside Mac manual. The Forth word MT assumes that all parameters on the stack are in their correct 32-bit format, and a toolbox call defined by MT will leave the stack unchanged before executing the trap. On execution, the parameters are cleared from the stack.

If the routine expects any 16-bit parameters (16 and 32 bits are the only possibilities), it would be a little difficult to push them on the stack correctly, since MacForth generally assumes stack items to be 32 bit long (in contrast to standard FORTH-79). Most toolbox traps, however, need at most two 16-bit items, and they are at the end of the parameter list. MacForth provides the two defining words W>MT and 2W>MT for calling traps that need one or two 16-bit parameters. These parameters can be pushed on the stack as 32-bit items and are automatically adjusted to 16 bits before the trap is executed.

Last type of toolbox calls are Pascal functions. The calling convention here is that one has to leave space on the stack for the result and then push the parameters. The function will clear the parameters from the stack upon execution and leave the result in the space provided. Four types of calls are provided through the defining words FUNC>W, FUNC>L, W>FUNC>L, L>FUNC>L,for functions (in that order) that use no parameters and return a 16-bit item, no parameters/32-bit result, 16-bit parameter/32-bit result, 32-bit parameter/32-bit result.

The line 1111 instruction

If you decompile and disassemble the code that is produced by the trap defining words, you will see that some of them contain instructions that start with a hex F. Here MacForth makes use of the other set of unimplemented instructions (line 1111 emulator) of the 68000!

Read this over again, it is important. The MacForth implementers have really made a fine use of the 68000 traps that are available. Not only are the 4E type traps used in making the threaded code fast (see my last article), here is the 1111 line trap, too. The Motorola 68000 Programmer's Reference Manual (you have it by now, haven't you) tells you where the trap vector is, it is hex 2C. At this location you find (in MacForth) the 32-bit number hex 5614. The code at $5614 looks like that shown in fig. 1.

Beautiful: A word that starts with hex F is a negative 16-bit number and can therefore be used as a negative offset into an address table that is below the base location that A4 points to. As an example, let's see how an OS trap defined through OS.TRAP is executed. Assume you defined READ like above. Then the word READ will generate the threaded code:

 FFEC [F line trap for OS.TRAP]
 A002 [READ OS call]

A4 points to $55C4 in Forth 1.1. $FFEC added to A4 gives $55B0, at which location we find the address $1850. Offset from A4, we find ourselves at $6E14. The code there is shown in figure 2.

As you see, the trap word is moved into the routine that sets up the parameter register and executes the OS call. You may try and disassemble the definitions of the Pascal function call defining words; they also work through the 1111 line trap.

'Exotic' procedure calls

Though I do not recommend to do so, you might have written your own assembly language routine that requires a 16-bit parameter on the stack somewhere in between the 32 bit parameters and therefore you cannot use one of the defining words to call it. Here is a little trick that does the job. Since MacForth does not provide a word that pushes a 16-bit value on the stack and decrements the stack pointer by only two, we define our own. The base of the stack can be accessed through the variable S0, SP@ fetches the current stack pointer and SP! stores the value of S0 in the stack pointer.

:  PUSHW  S0  @  >R  SP@  2-  S0  !
SP!  R>  S0  !  DROP  ;

is our 16-bit push. After this, of course, the stack will be screwed up for most practical Forth purposes, so be sure to use it only if you a. want to call a procedure that expects a 16-bit parameter at this position on the stack or b. if you use it twice to make a composite 32-bit item on the stack from two 16-bit items.

Windows and Controls in MacForth

The last topic that I want to deal with in this issue are some points about windowing on the Macintosh. Those of you who read David Smith's article on assembly language have probably already got a feeling how involved this can get. Even setting up a window takes quite some effort. Fortunately, the MacForth system takes most of the load off our shoulders.

The FINGER.PAINT example in the MacForth manual illustrates the ease with which basic windowing functions such as opening, closing, dragging, resizing and tracking the mouse are handled; the word DO.EVENTS takes care of many of these functions. However, the MacForth system support does not go beyond those basics. More complicated things like scrolling must be handled explicitly by you, the user. The reason for this is simply that opening, closing, dragging and sizing are functions that are handled by the Window Manager while a scroll bar is a control for which the Control Manager is responsible. Controls are supported by MacForth Level 2; Level 1 does not document controls, although some of the definitions that are used in control handling are already present in Level 1.

For example, you can add scroll bars to any window by adding the constants SCROLL.UP/DOWN or SCROLL.LEFT/RIGHT to the window attributes. Try this in the windowing example from the Level 1 manual and then click the mouse in one of the scroll bars.

Of course, the bars don't scroll anything since DO.EVENTS does not support them. In order to be able to use these and other controls, we have to go through the Control Manager. Level 1 owners, you don't have to quit here, controls are a standard concept of the Macintosh that is supported by the Mac system and may be used from anywhere, FORTH, machine language, Pascal, C, even BASIC. It is only a little simpler in Level 2 because some of the things that we have to define for ourselves are already there.

In the next issue we'll look at the Control Manager and how to use it from Forth.

FIG 1
$5614 ADDQ.L#2,SP  discard status  register
 MOVE.L (SP),A0  saved PC -> A0
 MOVE   (A0)+,D0 F-trap word ->D0
 MOVE.L A0,(SP)  updated PC ->     stack
 MOVE.L 0(A4,D0.W),D1get address of  trap routine              rel. to 
A4 -> D1
 JMP  0(A4,D1.L) jump to this routine relative                 to A4

FIG 2
$6E14 MOVE.L(SP)+,A1 put PC into A1  (points to OS             
 trap word to be executed)

 MOVE  (A1),$1858(A4)get trap word & 
 put into $1858(A4) =     $6E1C

 MOVE.L (SP)+,A0 OS parameter pointer -> A0

$6E1C AXXXTrap goes into  here. Yuck!  Self-                   modifying 
code!

 MOVE D0,A0 result code
 MOVE.L A0,38(A0,D7.L)  save in    IO-RESULT

 JMP  (A4)get next Forth  token and  ...                 execute