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.

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.

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.

Code generation
===============
We have a newer VM code generator which is more like a full compiler,and which
we still hope to release. It can generate C source, assembler source or, most
interestingly, object code. It takes a somewhat beefed up 'Slang' (our name for
the VM pseudo code language) which does not allow any #cCode: escapes (not
possible when you want to go all the way to obj code!) and requires a somewhat
more careful approach to writing. At one time we did actually have re-written
VM code, but it is very out of date now.
As a way of generating primitives it could be very useful I think. I know Hans-
Martin has been doing some work on a similar idea as well. I suspect that being
able to filein ST code, generate a prim and run it on the fly might be a good
way around some problems. Indeed, it might make it practical to auto-generate
wrapper calls to external code, handling the parameters properly.
Somebody would have to handle the back-ends for non-StrongARM cpus - though of
course there aren't many machines of importance that use anything else :-) 

tim

-- 
Compatible: Gracefully accepts erroneous data from any source.
Tim Rowledge:  rowledge at interval.com (w)  +1 (650) 842-6110 (w)
 tim at sumeru.stanford.edu (h)  <http://sumeru.stanford.edu/tim>