Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!cbnewse!cwpjr
From: cwpjr@cbnewse.att.com (clyde.w.jr.phillips)
Newsgroups: comp.lang.forth
Subject: Re: Forth calls C
Summary: Simpler facility envisioned
Message-ID: <1991Feb25.170323.17130@cbnewse.att.com>
Date: 25 Feb 91 17:03:23 GMT
References: <9102221434.AA04459@ucbvax.Berkeley.EDU>
Distribution: na
Organization: AT&T Bell Laboratories
Lines: 68

In article <9102221434.AA04459@ucbvax.Berkeley.EDU>, wmb@MITCH.ENG.SUN.COM writes:
> > ... 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

I had something simpler in mind. It may be that what I see is useful
but won't solve the complete problem ( from a vendor or user pov ).

One service would be support for argument conversion.
This is essentially point 4 above. Being ignorant of the current
dpANS string wordset I can't spell it out here. Seems
a counted AND null padded string could be used counted for FORTH
and address +1 could be handed to C routines.

Does issue 3 above refer to non-stack passed calls?

Clyde