Conference hydra::amiga_v1

    I've used it somewhat, and my experiences with it have all
    been favourable. It's reasonably fast (purely subjective,
    I haven't run any benchmarks on it) and very powerful.
    
    Accessing system code (libraries, system calls, etc) is very
    easy since CSI gives a set of includes for FORTH-ized
    "structures" which are very easy to set up, and offsets are
    defined for all system entry points. This makes the task of
    interfacing with all Intuition/Exec/DOG/etc routines a very
    simple one. Another nice thing it has is "local variables" -
    a way to treat items on-stack as if they were VARIABLEs. Not
    in the FORTH philosophy, granted, but very useful all the
    same when you don't want to do a lot of DUP/OVER/PICKs.
    
    Coding is file-oriented, not the usual FORTH screens. Whether
    this is an advantage or disadvantage is a religious issue.
    
    MultiFORTH was originally implemented for the Mac, and is
    VERY optimized for the 68000. They explain many of their
    implementation decisions in the manual (which is, by the
    way, very well written). The Amiga version is very Amigaized
    and definitely not a cheapo port of the Mac one.
    
    In conclusion, I'd say you can't go wrong for $89.
    
    If you want more info send me mail, I have a copy of parts
    of the manual that I could loan you for a lookover.

	With regard to Multi-Forth: Does it support access to the
	fast floating-point routines ? Also, is it easy/hard/impossible
	to attach assembly-language routines to it ?

	A related question: Does anyone have experience with the other
	Forth implementation, J-Forth from Delta Research ?  The price
	is in about the same range, and they make  some pretty hot claims
	for its speed (350,000 loops/sec; complete sieve in 9 sec).  How
	does Multi-Forth stack up against those numbers ?

	For that matter, how are Multi-Forth/J-Forth when compared to
	object code from something like Manx-C ?

	I'm really fascinated by Forth, but I don't want to give up any
	crunching power.  Any feedback would be much appreciated.

		Art

	"BOUNDED CHAOTIC MIXING PRODUCES STRANGE STABILITIES...."

    No idea about the FFPs - in general, the best way to do floating
    point in FORTH is to not do it in FORTH (ie. the Zen method ;^).
    I'm not familiar with the FFP routines, but if they're in
    standard Amiga shared library format, all you need is the
    displacements into each routine to be able to use them.
    
    Don't know how familiar you are with FORTHs in general, but 
    assembly language coding is as easy as saying ASSEMBLER followed
    by your code (in RPN, of course!). However, MultiFORTH has some
    nice primitives (!reg and @reg) for reading/writing the registers
    from within the FORTH context, which is useful for library calls.*
    
    * Before you ask: Most register writes in the FORTH context are
      "buffered" until the next library call so as not to interfere
      with MultiFORTH's usage of the registers.
    
    A friend of mine compared MultiFORTH and J-FORTH and found he
    preferred the latter. It's faster, screen-oriented (he's more
    of a purist than I am), but isn't quite as Amigaized. The reason
    it's faster, I believe, is because J-FORTH is sort-of-compiled.
    Don't ask me what I mean by this, it's something I heard a long
    time ago and forgot the details to. Anyone know more about it?
    Incidentally the reason MultiFORTH came down in price is because
    J-FORTH came out for 1/2 of its price. Luv that free market!
    
    In theory, good FORTH code should always be faster than code
    generated by a HLL compiler. In practice, this isn't always the
    case. Due to the FORTH cell structure being only 16 bits wide,
    an artificial 64K boundary is always set up such that references
    outside this area involve more overhead. And in an Amiga with 
    16M of address space, there's a lot of calling outside your
    64K chunk! Also, the implementation of subroutine calls on
    the 68000 is somewhat less than optimal, and FORTH relies
    on these very heavily, whereas most C code is very in-line.
    
    In general, I should say it depends on how well the code is
    written, what it does (lots of crunching vs. lots of hopping
    around), and particular quirks/instances ("Gosh, this C
    compiler optimizes this code so as to shave off 2 ns in
    certain instances of a for() loop, assuming Vega is in the
    5th quadrant of the sky"). The only way to really find out
    is to use them both heavily. Or do some benchmarks, if you
    believe in those.

    I own J-Forth since a few days only and had no much time to go thru
    it, but I've already discovered that's fantastic.
    Speed comparison.
    	Sequence		Multi-forth		J-Forth
    (1,000,000 seq.)
    Empty Do loop		14.14			2.86
    Swap			11.22			4.64
    DUP DROP			11.14			3.54
    23 45 + drop		26.06			8.62
    Sieve ( 10 loops)		21.48			8.82
    
    More IMPORTANT :
        
    J-Forth is an implementation ( Multistandards, BTW) in fully
    
    		32 bits !!!
    
    This means that there is no limitation to 64K of vocabulary space.
    It is FULLY AMIGAZED . Plenty of primitives to implement easily
    any amiga function. A PD example shows haw to implement a PAINT
    program that uses HAM with 4096 color at a time.

        It's impressive how fast it is. This is due to the JSR-Threading
    and to the choice of substituting a CALL with the original code if
    the SIZE of the called function is below a parametrized threshold.
    
    The documentation is excellent, if you are already familiar with
    FORTH ( no tutoring of Forth, so you still need Starting Forth by
    Leo Brodie if want to start from scratch).
    
    There is a utility H2J that transform any include  ( xxx.h)
    C file to a new include file for Forth ( xxx.j).
    
    There is also floating point full supoport but my religion is against
    it, so I don't have information handy. 
    Conclusion:  VMF ( Very Much Satisfied)
    Price paid : 105$ COD

    Well, I got Multi-Forth a week or two ago, which explains my apparent
    absence from this note.  I was going to rebut the benchmark stuff
    based on MF's (love that acronym) documentation, but I really don't
    care right now; I feel, and recommend, that one go for ease of use
    first, and then worry about speed.  MF seems good on ease of use.
     Forth is preety good on portability, so if J-Forth is faster, you
    could port to it.  
    I'm a beginner.  I've got a program that opens a screen with a window
    that uses a superbitmap.  It works o.k until I resize the window.
     Any image in the window disappears.  I've seen the usenet posting
    about the locklayer/syncsbitmap/copysbitmap/unlocklayer.  My problem
    is (I think) that the layer calls above have "Layer" as the argument.
    How do I get the layer?  And what layer; are there different
    layers for screen, window(s), etc.?  Right now I'm doing a 
    			rport +rpLayer @ LockLayer
    sort of thing for each of thhe calls, locking/syncing/unlocking
    on the SIZEVERIFY message an locking/copying/unlocking on the NEWSIZE
    message.  Any help is appreciated.
    Regards
    John
    

    update: I had some mismatched 'types' and once unscrambled, it sort
    of works; I now don't lose all of the image, only some of it, and
    I pick up some random junk.  The response doesn't seem to be repeatable
    on successive 'loads' and 'runs'; sometimes I get the original image
    plus a copy translated a little, in a different (also random) color.
    ???????  I always use the current windows rastport structure to
    get the layer.  I'm also not zeroing the superbitmap.  Anyone know
    what's happening?  Thanks
    John