[Openmcl-devel] Win32 questions

Joshua Kordani jkordani at lsa2.com
Thu Oct 16 08:17:13 PDT 2014

On 10/16/14 12:18 AM, Gary Byers wrote:
> To digress (hopefully very briefly): lisp objects are dynamically 
> typed; "foreign objects" generally aren't.  "Lisp memory" contains 
> lisp objects and is managed by a lisp-aware GC; "foreign memory" 
> doesn't contain lisp objects and is not generally of interest to the 
> GC.  C (and other foreign code) operates on foreign objects in foreign 
> memory and Lisp code operates on lisp objects in lisp memory, and the 
> twain only meets in a few places (foriegn function calls and 
> callbacks) in CCL.  There are a few ways of allocating and managing 
> foreign memory from Lisp code in CCL and of storing and accessing 
> foreign values in foreign memory; threre is (very intentionally) no 
> way of going in the other direction in CCL. Some of those ways of 
> allocating foreign memory allocate it on a stack.  Hopefully, that's 
> more than enough of a digression ...
> Using %STACK-BLOCK (as your annotation does) is more correct, but I'd 
> vote for using
> RLET.  (All of these things are fairly low-level, but RLET does a 
> little more for you.)
> Recall that a MACPTR is a lisp object that encapsulates some absolute 
> address.  WITH-MACPTRS will bind a set of variables to a set of MACPTR 
> objects and declares that those variable bindings have dynamic extent 
> (and therefore the MACPTRs which are the initial values of those 
> variables can be stack-allocated.)  A MACPTR is a few dozem bytes at 
> most, but code which allocates those small lisp objects on a lisp 
> stack may CG less frequently than code that allocated them in the lisp 
> heap.  The original code bound SN to a NULL pointer and passed the 
> value of that null pointer to the foreign fuinction; that's no 
> different than the other arguments where an explicit null pointer is 
> used.
> Your annocation used (%STACK-BLOCK ((SN 32)) ...)  That will allocate 
> 32 bytes on a foreign stack and bind SN to a MACPTR to the address of 
> that memory.  If the foreign function call returns with no error, you 
> could get the value that the function stored there by something like
>   (%get-unsigned-long sn  ; I'm assuming that a DWORD is a 32-bit 
> unsigned integer
> If you don't remember how big a DWORD is (but do remember how to 
> capitalize it), you could also use RLET and PREF here.
>   (rlet ((sn #>DWORD))
>     ...
>    (pref sn #>DWORD))
> In C, you might have just said
>    DWORD sn;
> and that's more succinct but it's exactly what the RLET is doing.
Thank you!!  I will look into these more.

Joshua Kordani
LSA Autonomy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20141016/460b83fa/attachment.htm>

More information about the Openmcl-devel mailing list