Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!usc!apple!bionet!agate!ucbvax!MITCH.ENG.SUN.COM!wmb
From: wmb@MITCH.ENG.SUN.COM
Newsgroups: comp.lang.forth
Subject: Forth calls C
Message-ID: <9102221434.AA04459@ucbvax.Berkeley.EDU>
Date: 21 Feb 91 22:46:07 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: wmb%MITCH.ENG.SUN.COM@SCFVM.GSFC.NASA.GOV
Organization: The Internet
Lines: 54

> ... discussion of allowing Forth to call external (e.g. C) library routines
>       Am I missing something or could this be easily solved by
> a Vendor supplying a standard ( ANS ) system interface that has
> built in support ( ie primitives ) for alternate form/sequence parameters?

In principle, it would be possible to do something like this.  The key
is to develop a specification language to describe the routine that is
to be called.

I have a fair amount of experience in this area;  I have developed "call
compilers" to allow Forth to call external routines for about a dozen
different forms of external routines/calling sequences/linkage mechanisms.

Here are some of the issues that a "call compiler" has to address:

        1) The name of the Forth word the calls the external routine (easy!)
        2) The stack diagram of the Forth word (easy!)
        3) The place to put the arguments to the external procedure
           (can be fairly tricky)
        4) Data type translation (for example, Forth and C have different
           string representations)
        5) Execution environment maintenance (for example, Macintosh system
           calls require particular handling of the A6 register).
        6) Linkage - how to find the actual address of the external routine,
           or its trap number or whatever, and how to get the routine loaded
           into memory.
        7) Callbacks - Forth calling C is only half the problem; most people
           eventually want C to be able to call back into Forth too (e.g. for
           I/O services)
        8) Error returns - many system call interfaces report errors
           separately from their normal return value mechanism.

I have yet to develop a specification mechanism that can handle the full
range of problems across all the environments that I have dealt with.
I usually end up "tweaking" my specification syntax to some extent for
each new system that I have to deal with.

This is one of those problems that appears straightforward from a
conceptual standpoint, but once you get down to the details, it tends
to get overwhelming in a combinatorial sense.

I cannot imagine in my wildest dreams that the ANS committee would ever
standardize something like this.  It is just too complicated.  Witness the
tremendous amount of discussion that has resulted from the CATCH/THROW
wordset.  CATCH and THROW is a simple, elegant, easy to describe, essentially
complete solution to a problem that pretty much everybody understands.
Yet it is has taken a lot of flak about being "experimental".

The external call problem has none of that simplicity and elegance.
I have never seen a proposed solution that I think is even reasonably
complete, and I have probably designed and implemented more approximate
solutions to this problem than anybody else.

Mitch Bradley, wmb@Eng.Sun.COM