Updates for Mach1 and Neon

By Jörg Langowski, EMBL, C/O I.L.L., Grenoble, Cedex, France, MacTutor Editorial Board

"In Our Mail"

This time, I have no specific subject to cover, but would rather like to address a few points that came up while browsing through my mail lately. Also, I want to inform you on updates of NEON and Mach1 that just came in. (Judging from the productivity of some of the developers, the next updates will probably be out even before this comes back from the printer's...)

We received a letter from Finland; Juri Munkki from Helsinki sent the following interesting note:

"I received my HD 20 yesterday and I found some problems with using it for Forth development using MacForth Level 3. The problems arise when trying to access files from directories outside the Forth folder [this seems to be one of the standard problems in HFS. J.L.]. I was very glad to see that my terminal program worked correctly with HFS and used that knowledge to add a new command to MacForth.

MacForth activates windows automatically when an activation event is received. This is not desirable when returning from a standard file-call because it interrupts the execution of the calling program. Before receiving Level 3, I used a special window for calling the standard file package and used two different activate procedures. Level 3 documentation explained the Event.Table and I was capable of simplifying the calling of these extremely important routines.

The main reason my program worked was that it used PBSetVol to change the default directory. This simple technique of calling SetVol after SFGetFile and PutFile allows me to use standard MacForth file commands without any modification of the internal structure FCBs.

The routine below [Listing 1] fits in one block (if left without comments) and is very helpful in using the HFS folders. "

Listing 1 : Select directory, by Juri Munkki

( Directory Mount utility)                     ( 011086 JAM)
create SFReply 76 allot
 SFReply 76 erase  ( standard file reply record)
create OurParams 32 allot
 OurParams 32 erase   ( our param block)
hex  A015  os.trap  SetVol   ( PBSetVol  OS  trap )
   A9EA  w>mt    Pack3    ( standard file package)
variable  act.ev.proc   ( standard action for activate )

: seldir ( lets the user choose a default directory )
 activate.event 2* event.table + w@ act.ev.proc !
 ( save old activate.event vector )
0 activate.event 2* event.table + w!
 ( disable vector temporarily )

 00400040 "  " 0 -1 0 wbury 0 0 sfreply 2 pack3
 ( call SFGetfile)
 act.ev.proc @ activate.event 2* event.table + w!
 ( reset activate vector)

 SFReply c@ if  ( file was selected)
 SFReply 6+ w@ OurParams 16 + w! 
 OurParams SetVol then
;

axe SetVol  axe Pack3  axe act.ev.proc  
axe SFReply  axe OurParams
decimal

"Just type SelDir and choose a file from the directory you want to work with. This directory is automatically vref 0 and can be shown by typing 0 dir. I thought that you might find this information useful to some MacTutor readers. "

Yes, we do, thank you for that contribution! I tested that routine - not using HFS, since I don't have 800K disks or a hard disk yet - but to change the default drive. After executing SelDir (e.g. on a file in the external drive), both 0 dir and 2 dir will display the external directory, and files without directory prefix will be looked for on the external drive. Saves a lot of hassle when one loads files from the external drive that include" files that are also on the external drive.

Indirect recursion and deferred execution

Another letter comes from Steve Pothier in Tucson, AZ, asking a question about recursion in NEON. I made a comment in the NEON article (MT V2#1) about the use of the forward declaration in recursion, which I did not further explain, so here goes:

As a matter of fact, simple recursion is generally allowed in NEON, while this is not the case in MacForth. As said in the mentioned article, one can circumvent this problem by resetting the smudge bit during compilation. Mach1 has the word recursive built in which does exactly this job, so the corresponding definition of the factorial would be:

: factorial   ( Mach 1 version )
 recursive
 dup if dup 1 - factorial * else drop 1 then ;

So we're pretty fine in any kind of Forth doing direct recursion, that is to say referencing a Forth word from within its own definition. However, indirect recursion is a different ballgame. If we want to reference word A from word B, which contains a reference to word A in its definition, we will have to reference one of the two words before it is actually defined. This is, of course, not possible in Forth. But the problem can be solved.

Lets assume we define routine A first, then routine B. Then the only way to refer to B from within A is to create a vector B.vect before defining A, referring from within A to B.vect instead of B, and setting the vector after having defined B. Lots of As and Bs here, an example will illustrate:

create B.vect ( and do something with it ...)
.... code to initialize the vector ....

: A .......
      .......   B.vect ( B is called here )
      .......  
;
: B .......
      .......  A  ( may be called in the normal way )
      .......  
;
.... code to setup B.vect so that it executes B when called ....

How do we do this in practice? NEON has the forward declaration built in. In case one needs to refer to a word that cannot be defined yet, one can 'pre-declare' this word by saying forward B and then using this definition of B in any other words following it. When one is ready to define B, the special defining word :F together with ;F is used to resolve the forward reference. As long as this has not been done, any attempt to execute B will result in an error message. The example from above then looks like the following in NEON:

forward B

: A .......
      .......   B ( B is called here just like any word )
      .......  
;

:F B ....... 
       .......  A  ( called in the normal way )
       .......  
;F 
( forward reference is resolved after this definition)

Standard Forth (-79 or -83) does not have a forward declaration built in. MacForth and Mach1 don't have it. MasterFORTH has defer, which does a similar thing as forward, defining a word whose action will be defined later. defer and related words are explained in the book 'Mastering Forth' that comes with the MasterFORTH package:

: undef.error ." not defined yet! " cr ;

: defer  create ['] undef.error ,
 does> @ execute ;

: is ' >body ! ;

defer is a compiling word whose runtime action is to execute the vector that it contains. Initially, this vector is set to the address of a warning message that is printed as long as the word has not been defined yet.

is stores the address on the stack into the body (Forth-83) of the word following it. This means if we define

defer my.vector
: test ." Hello world!" cr ;

and then say

' test is my.vector

execution of my.vector will result in "Hello world" being printed.

Now our indirect-recursion example from above would look like:

defer B.vect

: A .......   B.vect   ....... ;

: B .......  A  ....... ;

' B is B.vect 

Notice that these definitions are for MasterFORTH; Mach1 has a different structure (explained in my last column), and the definition of is has to be changed:

: is ( Mach1 version )  ' 4 + ! ;

MacForth has an even different structure; the corresponding definitions would look like:

: undef.error ." not defined yet!" cr ;                         
                                                                
: defer 
        create ' undef.error ,                                  
        does> @ >r ;                                            
                                                                
: is [compile] ' ! ;                                            

For MacForth, I have also given an example of Leo Brodie's DOER/MAKE vectored execution handler (V1#7). DOER/MAKE, of course, allows also for deferred execution, e.g.

doer B.vect

: A .......   B.vect    .......  ;

: B .......   A    .......  ;

make B.vect B

with the additional advantage that vectors can be made to execute other words from within definitions. I won't give the corresponding definitions of DOER/MAKE for Mach1 or MasterFORTH here; this is, as they say, left as an exercise for the reader.

Upgrades, improvements etc.

I just received updates of NEON (v 1.5) and Mach (Mach 1.1) in the mail. Many of the bugs that were still present in the first versions of these systems have been removed. Let me just give you an extract of the information that was sent to me together with the updates by Palo Alto Shipping and Kriya:

Mach 1.1

[excerpts from the letter by Palo Alto Shipping]

"MACH 1.1 SUPPORTS MACPLUS AND HFS

MACH 1.1 includes support for the new trap routines included in the new 128K roms and works under the Hierarchical File System. SWITCHER 4.6 is also included.

DEBUGGER REMOVED

A debugger is no longer included in MACH 1 for two reasons. One reason is that there is currently an abundance of inexpensive, high quality debuggers for the Macintosh. The second reason is that since the debugger was written in MACH 1, its performance was very dependent upon the integrity of the MACH 1 kernel. If the kernel ever became damaged, the debugger would often fail. The debugger chapter in the manual should be disregarded. [Too bad that this part of the system is gone. The single stepping mode with the ability to see Forth and machine code simultaneously was a nice feature. However, the debugger had its own bugs... Palo Alto Shipping is working on an improved version and planning to reinstall the debugger on future systems]

Note that the dissassembler is still included. [from which the addressing mode bugs mentioned in my last column have been removed / J.L.]

NEW WORDS

Six new words which run the default event-handling routines when executed have been added to the MACH 1 kernel. [to be used to stash into deferred execution vectors etc... / J.L.]

The following words which support the printing manager have been added to MACH1: [...]

PrCtlCall PrDrvrClose PrDrvrOpen

PrSetError PrError PrPicFile PrCloseDoc

PrClosePage PrOpenPage PrOpenDoc

PrJobMerge PrJobDialog PrStlDialog

PrValidate PrintDefault PrClose PrOpen

That's for the Mach1.1 update. It seems to me that with the extra printer support the spooler example form my last column could be upgraded into a real nice background spooler for Text and Paint files. The upgrade furthermore contains a second disk packed full of demos, some of which are rather sophisticated application examples (e.g. a TextEdit example and one that uses the printing routines). Also includes is a 3-d fractal demo that draws mountain shapes. Nice to look at.

NEON 1.5

The main additions to the new NEON 1.5 are listed below [words by Kriya Systems]:

"Here are the functional differences between Neon v1.0 and v1.5. [ ]

Features added:

• Floating Point support; use "neonFP.com"

• All source for rebuilding Neon up from the nucleus is released

• New classes have been included: LinkedList, 2dArray, Dictionary, etc

• New utilities have been included: Decompile, PrintAll, Words, etc

[The Decompiler supplied by Kriya works only on Colon definitions. One that gives also at least some informations about class definitions is still a project for this column. / J.L.]

• Neon™ v1.5 is compatible with the new Neon™ Assembler

• SORT is a new word which performs a shell sort

• $= is a new word which performs a relative compare on strings

• LAND, LOR & LXOR are new words which are the logical counterparts to the bitwise AND, OR & XOR

• PUSHPORT & POPPORT are new words for keeping graph port record pointers on the data stack

• PARAMTEXT is a new word for use with dialogs which sets text substitution strings for Static and Editable text items

• CALLER is a new pseudo-ivar, like SELF or SUPER, which late binds a message to the calling object. (This must be used inside a method.)

• The fill: method has been added to String

• A disp: method has been added to each of Picture, Alert, Rect & Icon

• The putText: & getText: methods of Dialog now work on control items

• The status of the cursor is now preserved during Neon functions

• You may now grow the Neon window to the full size of a MacXL screen

• Compile echo now functions for modules

• WORDS now formats it's output according to the width of the window

• The Install dialog now includes the "Max Heap" button

Bugs fixed:

• The name field for SIGN is fixed and is now findable

• The U* presicion bug has been fixed; (*/ & M* also)

• PURGE has been modified to work on megabyte Macs

• The fill: & new: methods of Array have been fixed

• The put: & click: methods of Mouse have been fixed

• The charOf: method of String has been fixed

• The print: method of Timer has been fixed

• The baud: method of Port cleans up the stack properly

Functions changed:

• FINFO returns a relative address

• STDGET takes a specification of up to four file types

• The words MLOCK, MUNLOCK & ?MLOCK now take the cfa of a module

• NULL & BYE are now defined above the nucleus so that they may be called from menu selections defined through the use of getMtxt.

[Before, it was very important when making stand-alone applications, to define 'calling words' for BYE and NULL, which were part of the nucleus, and use those 'super-definitions' in menu files. Otherwise, the menu handler would not find the NEON word corresponding to the menu item when the menu text was loaded at runtime, causing a crash. This was the reason for the crash of my text edit example in the Feb 86 issue; I forgot to include a new definition for NULL just like the CIAO definition for BYE]

• The word FF (form feed) has been renamed to NP (new page)

• QUIT now clears menu bar hilites

• The Grep utility now prints the file name only when a match occurs

• ASCII no longer shifts alphabetics to upper case

• The grow: method of Window does not clear the window

• The actions: method of vScroll has a clear: parts

• The Apple menu now accomodates up to 22 items".

[Other observations:

Since I have not upgraded my systems to the large drive, new ROMs and HFS yet (I'm reluctant to do so as long as there is no working version of Fortran available for HFS), I cannot judge whether NEON 1.5 will work correctly with the new system. Any comments on this by readers will be greatly appreciated.

The fix for IC!

Since Kriya Systems don't seem to have noticed, here's my fix for IC!, which makes this word work correctly (did this by disassembling the kernel and looking through the file with Fedit):

The code that has to be fixed starts at relative address $13B4 (absolute $E044 in my system) in both NEON 1.0 and NEON 1.5:

13B4: 2E16 MOVE.L (A6), D7

13B6: 568F ADDQ.L #3,A7

13B8: 179F 7800 MOVE.B (A7)+, 0(A3,D7)

13BC: 2C1C MOVE.L (A4)+, D6

13BE: 2E33 6800 MOVE.L 0(A3,D6), D7

13C2: 4EF3 JMP 0(A3,D7)

For some reason, the ADDQ in connection with the MOVE.B does not seem to do its intended job (Can anyone help me; 68000 machine code specialists, please). The code works if you change it to:

13B4: 2E16 MOVE.L (A6), D7

13B6: 201F MOVE.L (A7)+, D0

13B8: 1780 7800 MOVE.B D0, 0(A3,D7)

13BC: 2C1C MOVE.L (A4)+, D6

13BE: 2E33 6800 MOVE.L 0(A3,D6), D7

13C2: 4EF3 JMP 0(A3,D7)

The way to install this patch permanently is by using Fedit or some similar program. Open the NEON file and search for the hex sequence 568F179F. Verify by looking at the code around it that you have really found the correct piece of code. Then replace this sequence by 201F1780. Now rewrite the sector to your disk (HOLD IT! You did make a backup first, I suppose?). This should give you a working IC! in your NEON kernel.

Questions, comments etc. may now also be addressed to: LANGOWSKI@DHDEMBL5 on BITNET, or, if you are using BYTE's BIX system, you can leave mail under JLANGOWSKI for me or MACTUTOR for David Smith.

See you in a month.