[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