LS FORTRAN 2.1; Forth News

By Jörg Langowski, MacTutor Editorial Board

After our excursions into the world of MacApp and C++ (which will be continued), this month will get us back to FORTRAN and Forth - somewhat closer to the ground, some may say. Language Systems just sent me their latest update of FORTRAN for MPW, and I’d like to show you some of its new features.

FORTRAN background processing

One of the main improvements is automatic background execution. Assume you are porting a program from a mainframe to the Macintosh. FORTRAN programs on big machines are often written to compute some output, given some input, in a rather ‘linear’ style, that is, user interaction occurs only at some predefined points in the program. As an avid reader of this magazine you will know by now that Macintosh programming (and, for that matter, programming of other graphical user interfaces such as XWindows or MS Windows) is done differently; the program should only do small pieces of its operation at a time, and check for user events (mouse down, key down, etc.) as often as possible. This is done by making the program cycle through a main ‘event loop’, and do time-intensive tasks only at times when there are no such events to be handled.

The average data treatment, curve fitting, numerical simulation, etc. program that has been running on a VAX or some other machine will not be structured with a graphical user interface in mind. It will also be several thousand lines long, have gone through the hands of three generations of programmers, and, politely speaking, not adequately documented. However, it works, so how can we port it to the Macintosh with the least hassle, but please make it run in the background so that the work gets done while one is preparing the paper which was due three days ago (as I’m doing right now with this column, while a Fortran program is actually running in the background)?

One must find a mechanism by which the computation is broken up into little pieces, after which the program can return control to the operating system. As some of you might recall, a while ago I presented such a mechanism: at each point where you want the program to return control, insert a call to WaitNextEvent with an event mask that checks only for update and suspend/resume events. As long as WaitNextEvent receives only null events at those control points, the program will continue to do its work, advancing from WaitNextEvent to WaitNextEvent, whether it is in the foreground or in the background. When the mouse is clicked, the usual task switching will occur.

Of course, one must be careful about placing the WaitNextEvent calls; spaced too far apart, foreground execution of other applications will be ‘chunky’ when the program is turning in the background, and too many calls can slow down the Fortran program considerably.

Language Systems, in its Fortran 2.1, has integrated a ‘be-nice’ routine, F_DoBackground, into their libraries. A call to this routine causes events to be checked, and if necessary, control will be transferred to another process.

It would still be a lot of work to include calls to this routine into an existing Fortran program; therefore the 2.1 compiler adds a new option, -bkg=n, to its command line switches. If you use this switch with n greater than 0, you tell the compiler to add calls to F_DoBackground to your code automatically. The value of n controls the frequency at which calls to the backgrounding routine are made:

n=0: the default (and the way the old compiler worked): background processing is possible only during input/output to the console window.

n=1: F_DoBackground is called during file operations or console I/O.

n=2: F_DoBackground is called at each entry to a subroutine or function.

n=3: F_DoBackground is called before each labeled statement.

n=4: F_DoBackground is called inside each DO loop.

There are more possibilities to influence the frequency of F_DoBackground calls. Another library routine, F_SetBackInterval(ticks) will tell the system not to do a background call unless the specified number of ticks have elapsed, if otherwise your program would slow down unnecessarily. If you have some critical code that has to run uninterrupted, you can also insert a compiler switch into your source code that turns off the automatic insertion of background calls, and later turn it back on again.

Some Benchmarks

I have checked the backgrounding capabilities of Fortran 2.1, running a rather extensive curve fitting program that consists of several tens of modules that call each other, together with some subroutines for matrix operations. The program consists of two parts, an initialization part which is one rather lengthy calculation, and the curve fitting itself which runs iteratively, writing intermediate results to disk on each loop.

All results have been obtained on a MacIIx at Fortran optimization level 3. Using the old Fortran 2.0, the program used 43 s for the first part and 715 s for 65 iterations of the second part. The new Fortran 2.1 cut the execution time down to 38 s for the first part and 595 s for the second part, using backgrounding levels of 0 or 2 and running the program in the foreground.

If the backgrounding level is set to its maximum of 4 (that is, background calls on every labeled statement and in every DO loop) for all parts of the program except the low-level matrix algebra routines, the program executes quite nicely in the background and one can do some other work in a reasonable way. Typing text into WriteNow while the program was running, its execution time was slowed down to 40 s for the first and 690 s for the second part; still faster than for the previous Fortran version.

As you see from these numbers, code generation was also improved compared with Fortran 2.0. Not all benchmarks run faster, though; the single precision Whetstone program still ran at 1050 whetstones/s, which is close to the old value.

Incidentally, I have not received a copy of the new Absoft MacFortran II for testing yet; I would certainly like to compare that compiler to LS Fortran. In their latest ad - here in MacTutor - they claim their code is more than twice as fast than Language Systems’ (for the Whetstone benchmark). I would like to verify this and tell you about it in a later column. Absoft, are you listening?

Object-oriented Forth: Mops, a NEON clone

Some months ago (V6#5) I told you about a NEON clone that had been created by Michael Hore in Australia. He baptized his product Mops, for Michael’s Object Programming System. I would like to describe Mops in more detail now, and give you some programming examples.

First, for those of you who have never heard about NEON, I’d like to recall quickly the most basic facts about this object-oriented programming environment. Several years ago, Charles Duff created NEON which was then marketed by Kriya Systems. It was a language based on Forth, but let users write object-oriented code in a very non-Forth like manner. For instance, if you had defined a class of drawable objects, shape, you could declare

shape a
shape b
and then write 
draw: a
draw: b

which would display those objects according to a draw method defined in the class declaration. That method, in turn, would be written in a mixture of Forth and method calls like the ones you’ve just seen. A class declaration in NEON looked like

:class circle <super shape
\ instance variables
 point center
 int radius
\method declarations
 :m draw: 
\ code for draw: follows here
 ;m

 :m init:
\ initialization code follows here
 ;m
\ etc. etc.

;class \ end of circle declaration

Unfortunately, Kriya stopped updating - and selling - NEON a while ago, and the problem whether its source code is ever being made public domain is unsolved as yet. And might remain unsolved for a long time

Thus, and I wrote some notes about that in May, several people set out to iron out bugs in NEON, make it work with new Macintosh system releases, or even re-implement it from scratch. Mops is such a NEON reimplementation that is public domain. After (hopefully) watering your mouth for that system, I’d like to give you some details this time and encourage you to write to Michael at the address given at the end of this column. If you send him two disks he’ll copy Mops to it and send it to you. Now, some extracts from the Mops documentation:

“In Mops, we had the problem that native 68000 code only allows a 16-bit displacement for addressing [note that Mops uses subroutine-threaded code, just like Mach2 - JL] , every part of the dictionary must be within 32K of where an A register is pointing. The 68020/030 chips have a 32-bit displacement mode, but the 68000 doesn’t. The eventual solution was to dedicate three A registers for addressing. Mops uses A3 and A4 to address the main dictionary - these registers are set up with A4 pointing 64K higher than A3, and these two registers never change during execution. This way we can address a dictionary up to 128K in size. We call A3 “lobase” and A4 “hibase”. This scheme doesn’t really limit the total size of an application, however, since any number of modules can be used. These are addressed using A5 (“modbase”). Since Neon never allows a module to be accessed from outside except through an exported word, we maintain this rule in Mops, and thus we can ensure that A5 is always valid when a module is in execution.

We use A6 as the data stack pointer, and A7 as the return stack pointer. a Mops word can be called with a simple BSR instruction, and nothing further needs to be done with the return address, since it is already on the top of the return stack. All the words which call the system (such as TRAP) exchange A6 and A7 before the system trap, and then exchange them back on return.

In Mops we have been able to eliminate the methods stack. we use A2 for the base address of the current object in methods, and save nested object addresses on the return stack. We use D3-D7 for named parameters and local variables, and save as many as necessary on the return stack during nested definitions. Although this restricts us to 5 of named parms/locals instead of 6, I judged the gain in performance and the ability to eliminate the methods stack was worth it. Actually, in definitions with DO loops we can only have 4 parms/locals, since we use D3 for the loop variable I. I haven’t found this a very serious restriction in practice.

So to summarize the register usage:

D0-2  scratch
D3 I
D3-7  named parms/locals 
 (D3 available when not in a DO loop)
A0-1  scratch
A3 lobase
A4 hibase
A5 modbase
A6 data stack pointer
A7 return stack pointer

For speed, we normally hold all addresses in absolute form. We don’t therefore need the words +base and -base, and when doing @ etc. we don’t need an indexing step. This does mean, however, that we have to do some juggling to handle addresses that are stored in the dictionary and then saved in a dictionary image which is reloaded later at a different place in memory. For this kind of operation we have defined a relocatable address format, and the words reloc! and >abs to do the conversion The most common need for a relocatable address is for vectors.”

This was just to give you a look at some of Mops’ internals. Mops code looks very much like the old NEON code, with some cosmetic differences that come from the fact that Michael wanted to make the Forth syntax closer to the Forth-83 standard, and some syntax changes especially for late binding and heap object creation.

Differences to NEON

In NEON, when you wanted to send a message to an object whose address was on the stack but whose class was determined only at run time, you wrote:

message: [ object_address ]

Since Michael Hore wanted to use the square brackets for its original purpose, namely to turn compilation off and on, he changed that syntax to:

object_address message: **

When you wanted to create objects dynamically on the heap at run time in NEON, you wrote heap> classname which created an object of the appropriate class on the heap and left its address on the stack. In Mops, heap objects are handles, which themselves are objects to which messages can be passed. So in order to create a new object dynamically, now you first have to define a handle:

handle h1

and then use newObj: to create a heap object that this handle refers to:

‘ classname newObj: h1

You can lock the handle and get a pointer to the object by writing obj: h1. If you store that object pointer elsewhere (e.g. in an array as we do it in our example), you can re-use the handle and assign a new heap object to it. This is the way an array of towers and a list of disks on those towers is created in the Hanoi towers example in the listing.

Multiple inheritance

Mops also changes the syntax of superclass references in a class definition to implement multiple inheritance. Instead of writing, as in NEON

:class a <super b

you now write

:class a super( b c d )

where b c d are the classes from which a is derived.

There are more new features in Mops, such as optimization of the subroutine-threaded code, inline definitions and an assembly level debugger/decompiler. If you are interested, you should write to Michael and send two blank disks to get the whole system. Even though the version that I have still crashes sometimes, and the Install facility doesn’t work for me yet, it is a very interesting product and promises a great future.

I include the example code, the Mops kernel, the basic dictionary and some auxiliary files on the source code disk. To run the code, double-click the dictionary icon and select Load from the file menu when Mops has started up. Then load the demo code; ignore a warning message that comes up and simply type <return>. Start the demo by typing doit <return>.

The address of Michael Hore again, with some last comments of his own:

“I think I probably have a copyright on the Mops nucleus, which is pretty well completely original. This may well apply to a lot of the high-level stuff as well. Anyway, to the extent to which this is so, I’m releasing it into the public domain. Please address all comments, queries and (gasp!) bug reports to:

Michael Hore

I’ll do my best to respond to comments, etc. Even the bug reports.”

Thank you, Michael. Those of you who have access to Internet/Bitnet can as usual send mail to me at langowski@frembl51.bitnet. I’ll do my best to respond, too; in case you have trouble reaching Michael, I can also send a Stuffit file with the complete Mops system.

Happy threading.

Listing 1: Hanoi towers example in Mops

( Towers of hanoi in Mops )
( Aug. 90 jl )
( adapted from the NEON example in V2#1 )

: hanoi-towers ; \ for easy forgetting

:class tower super( ordered-col )
 rect base
 rect column
 int xcenter
 int ycenter

 :M classinit: ( xcenter ycenter -- ) 
 put: ycenter put: xcenter 
 get: xcenter 70 - get: ycenter 16 - 
 get: xcenter 70 + get: ycenter  put: base
 get: xcenter 4 -get: ycenter 
 limit: self 10 * 50 +  -
 get: xcenter 4 +get: ycenter 16 - put: column 
 ;M

 :M draw: 0 syspat dup fill: base fill: column ;M
 :M getX: get: xcenter ;M
 :M getY: get: ycenter ;M

;class

:class disk super( object )
 int size
 var which
 rect image
 int xc int yc

 :M classinit: ( which size -- ) 
 put: sizeput: which 
 addr: self get: which add: ** ;M

 :M draw: 
 get: which getX: ** put: xc 
 get: which getY: ** 12 - 
 get: which size: ** 10 * - put: yc
 get: xc get: size - get: yc 4-  
 get: xc get: size + get: yc 4+  put: image
 3 syspat fill: imagedraw: image 
 ;M

 :M undraw: 19 syspat fill: image
 get: xc 4- get: yc 4- 
 get: xc 4+ get: yc 4+  put: image
 0 syspat fill: image
 ;M

 :M move: { dest -- }
 undraw: self
 addr: self dest add: **
 get: which size: ** 1- get: which remove: **
 dest put: which
 draw: self
 ;M
 
;class

3 array towers

handle tw
 
: make.towers { ndisks -- }
 3 0 do i 150 * 100 +280 ndisks [‘] tower newObj: tw
 obj: twi to: towers loop ;

: draw.towers
 3 0 do i at: towers draw: ** loop ;

: dispose.towers 3 0 do i at: towers dispose: ** loop ;

: hanoi { n start inter finish -- }
 n if n 1-start finish inter hanoi
 finish at: towers start at: towerslast: ** move: **
 n 1- inter start finish hanoi
 then
;

: main  { ndisks -- }
 ndisks make.towerscls draw.towers
 ndisks 0 do 
 0 at: towers 6 ndisks i - 4* + 
 [‘] disk newObj: tw drop 
 0 at: towers  last: ** draw: ** 
 loop
;

: doit
 show: fwindselect: fwind 
 10 main
 10 0 1 2 hanoi
;

: demo doit bye ;