🚀 go-pugleaf

I was wrong when I typed earlier that A4th did not support libraries.  It does
do so, and allows one to very simply generate Forth equivalents to .fd
library definitions.

However, it is sort of brain-damaged for two reasons.  One is that it uses
self-modifying code to make the call which means it shouldn't run properly
with cache enabled on the 68020.  This is a must-fix at some point.
The other problem is that it uses movem instructions to load up the registers; 
this means that the stack ordering for a library call will be arbitrarily 
An..A0 then Dn..D0.  For example, OpenDevice's C calling sequence is:

	error = OpenDevice(devName, unitNumber, ioRequest, flags)
	D0		   A0	    D0		A1	   D1


The stack for the Forth call to OpenDevice is:

	ioRequest devName flags unitNumber -- error
	A1	  A0	  D1	D0

I think this is bogus because although there is a speed improvement from
movem, it is probably lost by all the dup rot swap required to set up
the arguments.  Many of the two-argument library calls seem clearly
backwards from what you'd want.  There is also something to be said
for having them on the stack in the order they appear in the RKM to
reduce programming errors and confusion.  As it is, you have to apply
the An..A0 Dn..D0 algorithm to figure out the calling sequence.


Finally, I'm thinking about starting a mailing list for A4th.  The reason
is that this stuff could start generating a lot of traffic that most of
the people here aren't going to want to see.  So if you would like there to
be an A4th mailing list (I'd run it from sugar) send me mail, especially
if you'd join the list (and mention this).  If interest warrants, I'll
set it up and post an announcement to the relevant groups.
-- 
-- uunet!sugar!karl  | "We've been following your progress with considerable 
-- karl@sugar.uu.net |  interest, not to say contempt."  -- Zaphod Beeblebrox IV
-- Usenet BBS (713) 438-5018