Calling 'straight' C code (was RE: Another silly
RITAMETZGER at prodigy.net
Thu Feb 18 04:35:21 UTC 1999
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.
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
>> Calling external code
>> There are several approaches to calling external code that might be
>> pluggable primitives is one very neat way but it relies on the called
>> 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
>> calling at all?) The obvious and well known approach to this is the
>> 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
>> Squeak. I did a version for the Acorn and the SUGAR guys did another
>> 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
>> know anything about the ST stack or anything else. There are some
>> 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
>> and even for longer term storage if you wrap some sort of object around
>> help with keeping/freeing it. I have code for a very simple system that
>> 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
>> 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
>> is not handled by the VM. Maybe if a fixed address (non-pointer object)
>> 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."
More information about the Squeak-dev