🚀 go-pugleaf

In article <BzH7AK.5s7@news.cso.uiuc.edu> schalk@symcom.math.uiuc.edu (Ken Schalk) writes:
>    I'm new to Forth and enjoying it immensely, but I have a question
>about stand-alone code segments, such as WDEFs and XCMDs.  Let me just
>say that I experienced in other languages (Pascal, C, C++, ...) and
>the Mac Toolbox, and have written both WDEFs and XCMDs in the past.
>    What I'm wondering is, is it possible to build such things with
>any of the Mac Forth incarnations?  (Personally, I am toying with
>Pocket Forth currently, as it is free.)  If so, how does the
>implementation go about building the code resource?  Does it just take
>a copy of the dictionary and add some setup code and a jump to the
>entry-point word at the beginning?  If not, what the heck does it do?
>
>    My guess is that it probably hasn't been done, as I think it might
>be kind of painful to turn a Forth dictionary (or some subset thereof)
>into a stand-alone code resource.  However, I think it would be
>wonderful if it were possible.  Having written these things in the
>past, I think the concept of a WDEF in Forth is a beautiful thing.
>(Heck, once you had the basics laid out, you could churn out WDEF
>after WDEF all the time, leading to a distinctive look for your apps,
>albeit a degeneration of the interface standard. :-)
>

	The following is excerpted from the MacForth 4 manual:

Stand-Alones: XCMD's, Drivers, ...

Overview

MacForth Plus 4.0 provides the capability of creating small stand-alone code
units, such as HyperCard XCMD's, FKEY's and drivers, from high-level MacForth.
Stand-Alones (or "SA's") run completely independent of MacForth and can be as
small as a few hundred bytes.  They do, however, execute code in the same
manner as MacForth (ie, using 16-bit tokens that are offsets from NEXT).  Most
words that are defined in MacForth can become part of a stand-alone; however,
there are some cases that require special care, as described below.  Additional
words are provided specifically to support XCMD's and drivers (which include
desk accessories).



	Although I have programmed in several languages on several different
machines I am relatively new to the Macintosh programming environment (and to
programming in Forth, for that matter) so I cannot respond to your other
questions.  Sorry.


	I guess I should put a disclaimer in here.  I have no connection with
Creative Solutions (the mother of MacForth) other than having purchased the
package from them and being glad that I did.


	I will also make a personal observation about PD versus Commercial
Forth packages.  I have used some PD Forth's in the past when I first
encountered the language.  Some are better than others (or vice-versa) and
they do provide you with a chance to get some hands-on experience with the
language; however, the ones I have used have tended to be pretty buggy and/or
have no (or little, or poor) documentation.  Consequently, I was never sure
whether the errors were mine (usually) or the Forth's (not un-usually).
Furthermore, when you are programming in the context of an operating system you
need tools to interact with the operating system.  Again, this tends to be a
weak area for PD Forth's in my (limited) experience.  I only have experience
with two commercial packages (one direct, the other second hand).  My direct
experience is with MacForth.  Although I am still learning my way around with
it, I have to say that it makes programming the Mac extremely easy.  The second
example was, a few years back when one of the professors on campus had just 
obtained -- ummm, memory fault; well, FORTH, Inc.'s package -- and he was 
ecstatic about it.  The *only* negative he had to say was something like: Gee, 
I'm sure glad I didn't have to buy this with my own money.  This was exceeded
by far with comments about how easy it was to use and how he could concentrate
on his project rather than fighting the language implementation.
	Well, this has been hashed over on comp.lang.forth before, and I don't
really want to restart that thread.  I just want to emphasize that you will
probably have to come up with money for a commercial product if you want to do
anything significant -- unless part of the attraction is to develop all your
own tools and debug Forth also.

Just my own thoughts.

Regards,
tony

In article <BzH7AK.5s7@news.cso.uiuc.edu>, schalk@symcom.math.uiuc.edu (Ken
Schalk) wrote:
> 
> 
>     I'm new to Forth and enjoying it immensely, but I have a question
> about stand-alone code segments, such as WDEFs and XCMDs.  Let me just
> say that I experienced in other languages (Pascal, C, C++, ...) and
> the Mac Toolbox, and have written both WDEFs and XCMDs in the past.
>     What I'm wondering is, is it possible to build such things with
> any of the Mac Forth incarnations?

>     My guess is that it probably hasn't been done, as I think it might
> be kind of painful to turn a Forth dictionary (or some subset thereof)
> into a stand-alone code resource.  However, I think it would be
> wonderful if it were possible.  Having written these things in the
> past, I think the concept of a WDEF in Forth is a beautiful thing.
> (Heck, once you had the basics laid out, you could churn out WDEF
> after WDEF all the time, leading to a distinctive look for your apps,
> albeit a degeneration of the interface standard. :-)

Actually, it's not really that hard depending on your architecture.
When I wrote SteveFORTH for the Mac several years ago, my main goal
was to produce a FORTH that had a kernel that was stand-alone and I/O
that was completely abstracted from the language.

The way I did this was to write a shell operating system in Think C.
The main() of SteveFORTH looks like this:

main()
{	
    MacInits();      /* InitGraf() etc. */
    GetDictionary(); /* load dictionary resource */
    MakeStack();     /* build the parameter stack */

    boot();          /* start execution */
    CleanUp();
}

Now imagine that we are writing a window definition function.  We could
just
do this:

pascal long main(varCode, theWindow, message, param)
short varCode;
WindowPtr theWindow;
short message;
long param;
{
    static short neverBeenCalled;
    long retval;

    SetUpRegisters(); /* do all the nasty a4/a5 mucking for globals */
    if (neverBeenCalled) {
        GetDictionary();
        MakeStack();
    }
    Push(varCode);
    PushLong(theWindow);
    PushLong(param);
    Push(message);

    boot();
    retval = PopLong();
    CleanUpRegisters();
    return retval;
}

In SteveFORTH there was a variable which was the address of the FORTH
function
to call on booting.  By default, it was a routine to make a window and
attach
standard input and output and call the interpretter, but you could easily
just
point it to your WDEF entry point:

ok ' myWDEF bootval !

and then execute the build application command from SteveFORTH's menu which
will build an application that you can extract the DICT resource and attach
to the application that will contain the above WDEF stub.

Here's how boot is defined:

boot()
{
    char *a; /* address of FORTH boot function */

    /* extract the address and add it to the base of the
     * dictionary.
     */
    a = DStart + *((short *)(DStart + BOOTVAL));
    asm {
        movem.l d0-d7/a0-a6,-(sp) /* save the world */
        move.l a,a0         /* copy the boot vector into A0 (scratch) */
        move.l stack,a6     /* set up parameter stack (and blow away a6) */
        move.l DStart,a3    /* set up dictionary base */
        move.l here,a2      /* load here */
        jsr (a0)            /* call boot function */
        move.l a6,stack     /* save stack */
        move.l a3,DStart    /* save dict base (could've moved!!) */
        move.l a2,here      /* save here */
        movem.l (sp)+,d0-d7/a0-a6 /* restore the world */
    }
}


Steve Hawley
hawley@adobe.com
--
"Did you know that a cow was *MURDERED* to make that jacket?"
"Yes.    I didn't think there were any witnesses, so I guess I'll have to
kill
 you too." -Jake Johansen