Letters

By David E. Smith, Editor & Publisher, MacTutor

Aztec C

Rich Heady

Aztec C is all I was told it would be, and I’m already pleased with the results. It is particularly gratifying to have access to “intermediate code” again after being locked inside Lightspeed C’s projects for the past 18 months, and more gratifying still to find the assembly code already optimized to the point where I may not need to go through cleaning up the little stupidities. There is nothing wrong with Lightspeed C; in fact, it remains a superior prototyping environment. But at the point where I began to look beyond the prototype to a shippable product, it was a relief to find Aztec C ready to finish the job. Aztec C might carve a bigger niche in the Macintosh world by appealing to the “1 Meg programmer” who wants to produce polished code without larding on RAM and without wading into the complexity of MPW.

Typos upon Typos

Ajay Nath

I’ve been writing a driver for my plotter, and I’ve been looking at the code you presented in MacTutor, Volume 3, Number 11 and 12. I’ve caught some errors in the code you presented on page 57 (#12). The code in the procedure DrvrStorage():

;1

asm {
 MOVEQ  #8, D0
 MOVE.L UTableBase, A0
 ADDA DO, A0
 MOVE.L (A0), OutDctlEntry
}

I wrote to you about this error before, but you printed my correction incorrectly! (You did print my explanation of why the author’s code was wrong correctly.) [Sorry, we will double our efforts. -ed]

On page 59 in the procedure MyPrDlgMain() at the end of this proc a pointer is freed and then accessed as follows:

/* 2 */

free(+p); /*ptr is being freed by a subroutine */
if (tp->fDolt) (void) MyPrValidate(hPrint);
 /*we accessed the ptr we freed */
return (tp->fDolt); /* you did it again! */

if (tp->fDolt) is true the subroutine “MyPrValidate” will be called, and it calls traps like GetResource and LoadResource which will move memory so that doing a subsequent “return(tp->fDolt)” may be pointing to garbage.

One way to fix this is to do the following:

/* 3 */

{ Boolean theResult; 
 /* a local variable to hold function result */
 
theResult = tp->fDolt; /*save the value of fDolt */
free (tp);
if (theResult) (void) MyPrValidate(hPrint);
return (theResult);
}

on page 58 in the procedure “MyPrintDefault(hPrint)” one of the lines:

**hPrint = **theDefault;

the same line appears on page 59 near the end of the procedure MyPrValidate(hPrint)

What the author is trying to do is to fill in the fields of the data structure that hPrint points to, what he actually does is mess up the hPrint handle. What he should do is something like this:

/* 4 */
BlockMove(*theDefault, *hPrint, sizeof(TPrint));

and probably:

/* 5 */

ReleaseResource(theDefault);
 /* unload resource now that we’re done */

It is a good article which provides information on how to write printer drivers, but some of the code is incorrect.

In MacTutor, Vol. 4, #11, the code presented by Donald Koscheka to do a string comparison uses the “DBRA” instruction incorrectly. When you loop using “DBRA” you use the word (16 bits) in the register you use as a loop counter; Mr. Koscheka uses register D1 as his loop counter and sets its value by doing:

 MOVE.B (A))+, D1; get length of string 1

This sets the lower 8 bits of D1, NOT the lower word. The correct way to load the value of the loop counter in this case is to:

;6

            MoveQ #0, D0; set D0 = 0;
            Move.B(A0)+, D0      ; D0 = string length

Also when using the “DBRA” instruction, the register must actually have the loop count -1 in it, i.e. if you want to loop 10 times, put 9 in the register. Mr. Koscheka doesn’t do this. I realize that he was showing a code fragment, but the purpose of his article was to show how to use assembly language and allowing such errors to slip in does readers a disservice.

FORTRAN Math Libraries

Michael M. J. Tracy

I am writing in response to Tatsuhito Koya’s request (Feb 1989, Vol. 5 No. 2) for information on FORTRAN math libraries that will run on the Mac. There is an excellent book out called ‘Numerical Recipes: The Art of Scientific Computing’ by William H. Press, Brian P. Flannery, Saul A. Teukolsky & William T. Vetterling (Cambridge University Press, ISBN 0 521 30811 9). I refer to this book infinitely more often than ‘Inside Macintosh’ when writing scientific applications on the Mac (and it’s cheaper too, about $35 hard cover). The book provides the source code for over 200 subroutines. Its real value to the user, however, is in the eloquent and intelligent discussion of the principles underlying each algorithm, explaining the strengths and weaknesses, and usually providing alternative algorithms so that the cautious user can cross check results. I have learned a lot from this book. Listing from the contents page, the book covers; solution of linear algebraic equations; interpolation and extrapolation; integration of functions; evaluation of functions; special functions; random numbers; sorting; root finding and non-linear sets of equations; minimization and maximization of functions; eigensystems; fourier transform spectral methods; statistical description of data; modeling of data; integration of ordinary differential equations; two point boundary value problems; partial differential equations. There are two versions of the book. The original edition gave the subroutine listings in both FORTRAN and Pascal. By popular demand, a second version was released which presents the C source code listings (written somewhat from the perspective of a FORTRAN programmer who wishes to convert to C, and provides structures and functions for handling complex numbers). Macintosh compatible disks containing the source code are also available from the publishers.

All FORTRAN subroutines that I have used work well, and have compiled without any problems under both MacFortran and Language Systems Fortran. Some subroutines, however, need to have the ‘SAVE’ statement added at the beginning (as required by the ANSI 77 FORTRAN standard) if local variables need to be preserved between subroutine calls, such as in the random number generators.

Further Optimizations

John F. Reiser

The code for optimized string comparisons (Letters, Jan. ’89, p. 106) is on the right track, but the listing contains a bug and the inner loop can be improved further. If the length of the first string is 128 or more, then the iteration count in register D1 gets an incorrect value via sign extension using EXT.W. The loop can be shortened by combining the break-out test with the iteration count control:

;7

A0 -> Pascal string 1
A1 -> Pascal string 2
D0 <- 0 if not equal, 1 if equal

CompareString  Moveq #0,D0; clear high bits
 Move.B (A0), D0 ; length of first string
@10Cmp.B(A0)+, (A1)+ ; mismatch?
 Dbne D0, @10  ; stop when .ne., or at end
 Sne  D0; D0.B = -1 if .ne.; 0 if .eq.
 Addq.B #1, D0 ; D0.B = 0 if .ne.; 1 if .eq.
 Ext.W  D0; Dbne can set bits 7-15
 Rts

VBL Animation Problems

David Oster

I am appalled by Dick Chandler’s article, “VBL Task Animation” in the February 1989 issue of MacTutor. Yes, his program works, but only because it is a top. Any real program that tries the technique he describes will fail miserably.

Look, his VBL task calls GetIcon and PlotIcon at VBL interrupt time. In his application, the main loop just busy waits for the user to press the Button. A real application would be calling GetNextEvent(), or doing something. For example, each time the user looks at a menu. When the menu goes away, it slams those bits back and deallocates the handle.

GetIcon calls GetResource(). What if the VBL task calls it while the Memory Manager is shuffling the heap to allocate memory for the main loop. Crash city. PlotIcon calls CopyBits(), which clips against the clipRgn and visRgn of the underlying grafPort. What if the VBL task calls it while the Memory Manager is shuffling the heap to allocate memory for the main loop? Crash city.

Even if your program is clean, you do not know what trap patches the user has installed: Maybe he is using an INIT that overrides some trap your program needs, and the override will do memory allocation. For example, Dick’s program calls Button() from its main loop, and many INITs override button, so they will get called while the mouse is down.

So, you can only do animation at interrupt time if you can guarantee that no user or system task will allocate memory in the main loop.

Dick’s program doesn’t guarantee this, since it calls Button() from its main loop, and Button() may have been overriden by an INIT. Since there is so little the main loop can safely do, you might as well give up on VBL Task animation, and just do animation in your main loop, busy waiting until TickCount changes to pause between animation frames.

TWindow Manager Update

Thomas Fruin

After a four month trek through the Latin American country of Peru (that left me penniless), I was delighted upon arrival at my fathers place in Santiago de Chile to find last December’s copy of MacTutor with my Tool Window Manager article. And the generous cheque that was included couldn’t have come at a better time!

Since the article was sent off to you, several programs have been written making use of TWindow. This caused a few small bugs to surface. I would like to take this opportunity to correct them.

The TWindow Manager incorrectly assumes that the calling application will always process every activate or deactivate event by calling TGetNextEvent. However, when multiple dialog boxes are put up, or dialogs following other dialogs without a call to TGetNextEvent in between, some activate or deactivate events may “linger”. This may cause the wrong (de)activation to occur when TGetNextEvent finally is called.

My solution is a utility function FlushActivateEvents(), with the following code:

/* 8 */

static void FlushActivateEvents()
{
 Booleanresult;
 EventRecordtheEvent;

 toBeActivated = toBeDeactivated = nil;
 result = GetNextEvent(activMask, &theEvent);
 result = GetNextEvent(activMask, &theEvent);
}

When called, this function effectively flushes (removes) every activate and deactivate event from the system: both official events and TWindow Manager internal events.

A call to FlushActivateEvents needs to be inserted in THideWindow and another call in TShowWindow. Both these calls should be made right after the very first if statement, where is checked if the window is still visible or invisible. That is all.

A minor oversight is that the WindowExists function is not defined static. It should be because it is internal to the TWindow Manager.

Finally, I can announce that I have written an MPW Pascal INTERFACE unit, that allows you to call the TWindow Manager from MPW pascal programs. This required more small modifications to the TWindow Manager source. As soon as I get someone to send me my disks from Holland, I will send the new versions of the software to MacTutor. By the way, this version of software also includes a TWaitNextEvent (although this is a trivial addition).

Publication of my article has definitely encouraged me to write more, so expect to see other stuff from me!

Absoft MacFortran to LS Fortran

Bert Waggoner

After over a year of reading your journal and programming the Macintosh things are beginning to make a little sense. Now I’d like to give a little back. Here are some notes on the new Language Systems Fortran compiler for MPW that you may wish to pass on to other readers:

I just received the Language Systems (LS) Fortran compiler v1.2 for MPW, and it looks very good. Now, using MPW, I can code in C and have access to the vast array of scientific subroutines written in Fortran (including those of my boss, who is reluctant to learn another language. We are developing chemical transport models for the Macintosh, and, until now, I have been translating his Fortran code to Think C. Microsoft C and Fortran for the IBM PC’s have been on speaking terms for some time - it’s about time the Mac caught up).

Here are some changes I had to make to get an Absoft MacFortran program to compile with LS Fortran:

- the preconnected file units for screen and printer I/O are reversed!

- any WHILE ( )/REPEAT loops must be replaced by DO WHILE ( )/END DO,

- LS Fortran doesn’t have a SELECT CASE statement (sigh),

- IF statements must have enclosing parentheses, i.e. use IF (X .EQ. Y) THEN, not IF X .EQ. Y Then,

- the ACCEPT statement must specify a format,

- there were several differences in filing handling, such as no POSITION or ACCESS key words for the OPEN statement IN LS Fortran.

There are, undoubtably, many other differences. As for toolbox access, LS Fortran’s implementation is different and cleaner, and the language allows for structures. Last, but not least, LS Fortran has a decent manual with lots of examples. Now my problem is converting my Think C code to MPW C. Would any readers like to share their experiences with this?

SysEnvirons From MacFortran

James Wishart

In the course of developing an instrument control and data acquisition application in Absoft MacFortran/020, I needed to call SysEnvirons to check for the 68881 floating point processor. Unfortunately, Absoft did not include the trap dispatch parameter for the call in their include files. With the help of additional documentation on the Toolbx.sub routine provided by Lee Rimar of Absoft, I found the correct parameter to be z’09014010'. The following program demonstrates how to call SysEnvirons in Absoft MacFortran.

c 9

program TestSysEnvirons
implicit none

integer*4 toolbx
integer*2 oserr, i
integer*4 version

integer*1 SysEnvRec(16)

integer*2 environsVersion
integer*2 machineType
integer*1 systemVersion(2)
integer*2 processor
logical*1 hasFPU
logical*1 hasColorQD
integer*2 keyBoardType
integer*2 atDrvrVersNum
integer*2 sysVRefNum

equivalence (SysEnvRec(1), environsVersion)
equivalence (SysEnvRec(3), machineType)
equivalence (SysEnvRec(5), systemVersion(1))
equivalence (SysEnvRec(7), processor)
equivalence (SysEnvRec(9), hasFPU)
equivalence (SysEnvRec(10), hasColorQD)
equivalence (SysEnvRec(11), keyBoardType)
equivalence (SysEnvRec(13), atDrvrVersNum)
equivalence (SysEnvRec(15), sysVRefNum)

integer*4 SYSENVIRONS
Parameter (SYSENVIRONS = Z’09014010')
oserr = 0
version = 2
do (i=1,16)
 SysEnvRec(i) = 0
repeat

oserr=toolbx(SYENVIRONS, version, SysEnvRec)

if (oserr .ne. -5501) then
 write(9,*) ‘environsVersion = ‘, environsVersion
 write(9,*) ‘machineType = ‘, machineType
 write(9,1) systemVersion(1), systemVersion(2)
1format(‘systemVersion = ‘, z2, “.”, z2)
 write(9,*) ‘processor = ‘, processor
 write(9,*) ‘hasFPU = “, hasFPU
 write(9,*) ‘hasColorQD = ‘, hasColorQD
 write(9,*) ‘keyBoardType = ‘, keyBoardType
 write(9,*) ‘atDrvrVersNum = ‘, atDrvrVersNum
 write(9,*) ‘sysVRefNum = ‘,sysVRefNum
endif
write(9,*)
select case (oserr)
 case (0)
 case (-5500)
 write(9,*) ‘System version is less than 4.2’
 case (-5501)
 write(9,*) ‘Bad version selector - no data returned’
 case (-5502)
 write(9,*) ‘Version ‘, version,’ requested, version ‘,
+environsVersion, ‘ returned.’
 case default
 write(9,*) ‘Unspecified error #’, oserr
end select

write(9,*) ‘Hit RETURN to exit program’
pause
end

A Usenet message from David Phillip Oster brought my attention to the fact that programs should watch for disk insertion events in their main loops and call DIBadMount if the inserted disk cannot be mounted. Implementing this feature requires two more undocumented trap dispatch parameter, DIBadMount (z’9E952200', routine #0) and DIUnload (z’9E908000', routine #4) from Pack2, Disk Initialization. The following code fragment uses the event manager variables defined in the example in the MacFortran manual. (Notice that the Pack2 routine selector must be added to the end of the argument list.) See Inside Macintosh Vol. 2 for the result codes returned in the two byte variable err.

c 10

select case (what)
 case(7)! 7 = Disk insertion
 if (shift(message, -16) .ne. 0) then
 call toolbx(INITCURSOR)
 err = toolbx(DIBADMOUNT, z’00640064', message, 0)
 call toolbx(DIUNLOAD, 4)
 endif

The remaining Pack2 parameters should be as follows, but I have not tested these: DILoad: z’9E908000', routine #2; DIFormat: z’9E949000', routine #6; DIVerify: z’9E949000', routine #8; DIZero: z’9E94E200' or z’9E94C200', routine #10.

I want to thank Jay Lieske for his “Fortran Printing Interface” article in August, 1988 issue as well as all of the people who contributed information about Classic Mac analog board failures. Every month I pace in front of my mailbox until MacTutor arrives.

Author Incentive Program Correction

Kirk Chase

In the December ’89 MacTutor, we made a correction on the Author Incentive Program initiated by Apple. Additional reimbursement is ONLY FOR APPLE EMPLOYEES. Those not employed by Apple DO NOT QUALIFY. We are sorry for any confusion that may have resulted over this and hope this clears up any mistaken notions. If you are with Apple, and if you want more information, please contact Stacey Farmer in public relations, who is now in charge of the program, for more information.