-----Original Message-----
From: RITA <RITAMETZGER at prodigy.net>
To: squeak at cs.uiuc.edu <squeak at cs.uiuc.edu>
Date: Wednesday, February 17, 1999 11:41 PM
Subject: Re: Calling 'straight' C code (was RE: Another silly
primitivequestion)


>WHO ARE YOU, AND WHY AM I ON YOUR MAILING LIST. I'M COMPUTER ILLITERATE, AN
>OLD ITALIAN WOMAN. I LOVE THE ATTENTION, BUT CAN'T UNDERSTAND THE LANGUAGE.
>THANKS ANYWAY, UNLESS YOU WANT TO SEND ME SOME CUTE JOKES, OR CAN EXPLAIN
IN
>20 WORDS OR LESS WHAT'S GOING ON, PLEASE TAKE ME OFF THE LIST. OF COURSE,
IF
>THIS IS THE MARS PROJECT, THAN PLEASE KEEP ME ON THAT LIST. THANK YOU,
RITA.
>-----Original Message-----
>From: Andrew C. Greenberg <werdna at gate.net>
>To: squeak at cs.uiuc.edu <squeak at cs.uiuc.edu>
>Date: Wednesday, February 17, 1999 8:22 PM
>Subject: Re: Calling 'straight' C code (was RE: Another silly
>primitivequestion)
>
>
>>Tim writes:
>>
>>> Calling external code
>>> ---------------------
>>> There are several approaches to calling external code that might be
>useful;
>>> pluggable primitives is one very neat way but it relies on the called
>code
>>> understanding how to get and use the parameters. For cases where it
>>> is feasible
>>> or desirable, that is a very effective technique.
>>>
>>> However, there are numerous cases where you would like to call
>>> directly to code
>>> that is expecting a more generic interface (dll, sll, acorn modules etc)
>>> typically corresponding to plain old C calling. (Do dll's still use
>pascal
>>> calling at all?) The obvious and well known approach to this is the
>>> systemcall
>>> primitive - which I think probably originated in Tek Smalltalk - that
has
>>> evolved various ways into things like PPS' CPOK (or DLLCC or whatever
the
>>> marketing geniuses last came up with) and which several of us have done
>for
>>> Squeak. I did a version for the Acorn and the SUGAR guys did another
>IIRC.
>>> Others have probably been written?
>>>
>>> Is there enough interest to try to build a concensus on a portable
>>> version? I'd
>>> suggest a prim that can call 'normal' external code, translating
>>> the parameters
>>> and return values in some manner. The called code would obviously not
>need to
>>> know anything about the ST stack or anything else. There are some
>interesting
>>> difficulties:-
>>>  some systems return more than one result, using a parameter block
>>> or whatever
>>>  some calls might expect to be able to write into a bunch of memory
>>>  some systems expect to have parameters that are structures or
>>> pointers thereto
>>>  how do you specify the translation from St to C
>>>  and back, for the result(s)
>>>  even naming the callee varies - some use address, some a
>>> meta-address, some a
>>> number, some a name.
>>
>>
>>I have done something like this.  I wrote a PluginPlugin, which
>>provides an interface to the native external library facilities (in
>>this case macintosh), providing for loading of the library, and
>>access to the several symbols therein -- which can then be wrapped
>>and specialized for direct calls to the external code.
>>
>>> Grabbing memory
>>> ===============
>>> On most systems, malloc/NewPtr/etc will work just fine for temporary
>storage
>>> and even for longer term storage if you wrap some sort of object around
>it to
>>> help with keeping/freeing it. I have code for a very simple system that
>just
>>> keeps a linked list in the VM of such 'FixedAddressObjects' that can be
>>> allocated by either ST code or external code. They go away when both the
>>> external code and ST have no more need for them. The simplest
>>> version restricts
>>> you to non-pointer objects (saves GC time & effort) but there is an
>extension
>>> to all types that works. We used it for sockets, display screens etc.
>>
>>I would like to see this code, if I may.
>>
>>
>>> External memory and external calls
>>> ==================================
>>> there is a possible interesting connection between the above topics.
When
>>> making external calls there is the problem of conversion of classes
>>> to types to
>>> handle. It is quite likley that one could find a conversion being needed
>that
>>> is not handled by the VM. Maybe if a fixed address (non-pointer object)
>block
>>> were created and filled with each parameter's converted value and
>>> then used as
>>> the source of call arguments? Conversion would be done by several
>>> methods (some
>>> primitive ) which would fill the parameter block. This would allow some
>>> extension without VM changes.
>>
>>I was thinking about something along these lines.  What if the VM
>>simply were to reserve a (configurable) block when booting (taking up
>>either a command line parameter or a number from a file, defaulting
>>to zeroK) which would be reserved for traditional heap calls below
>>memory and thus, transparent to the system.  The plugins would simply
>>choke in the traditional manner if there were insufficient memory,
>>and all that would need to be done is to change the parm and reboot
>>Squeak.  This seems like it should be as easy as adding a constant to
>>"memory" before starting up the VM, and then providing some
>>straightforward services to access the "fixed heap."
>>
>