[Openmcl-devel] macptrs and fasl file

Matt Claus matt at mclaus.com
Wed Oct 7 19:55:00 PDT 2009

Wow, thanks Gary. I pulled down the latest source and it works great. I 
sure appreciate your help and informative responses.


Gary Byers wrote:
> IIRC, SAVE-APPLICATION treats pointers to the low 64K and the high 64K 
> of the
> address space as being constants (things outside of that wrapped-around 
> range
> have their type changed to "dead-macptr".)  Those limits are somewhat 
> arbitrary,
> but it's pretty unlikely that addresses in the high or low ends of the 
> address
> space refer to dynamically allocated things.  My first reaction is to think
> that COMPILE-FILE should probably behave the same way (it currently refuses
> to deal with a non-null pointer constant.)
> There are a few other (very minor) issues related to pointer constants:
>  - pointers can contain at least some basic information about the type of
>    thing that they're pointing to.  I'm not sure that it makes sense to
>    treat a pointer that has this type information as a constant.  (Things
>    like #$IDC_ARROW are untyped, IIRC.)
>  - some pointers contain some extra info that makes them "GCable", which
>    means that the GC may have a way of deallocating (finalizing) the 
> foreign
>    object when the lisp MACPTR object becomes garbage.  It wouldn't make
>    much sense to try to serialize a GCable pointer (but it probably 
> wouldn't
>    make much sense to create a GCable pointer to the high or low ends of 
> the
>    address space, either.)
> I made that change in the trunk a little while ago; this issue comes up
> often enough that it or something similar should go in the next release, I
> think.
> On Wed, 7 Oct 2009, Matt Claus wrote:
>> Greetings,
>> I noticed some time ago that the mswin.lisp example loads and works fine
>> but fails to compile. I've had similar problems with my own windows
>> applications.
>> ? (compile-file "c:/wk/ccl/examples/mswin.lisp")
>> > Error: Can't dump #<A Foreign Pointer #x7F00> - unknown type
>> > While executing: CCL::FASL-UNKNOWN, in process listener(1).
>> The problem reduces to this win32 call:
>> (#_LoadCursorA (%null-ptr) #$IDC_ARROW)
>> The second argument to LoadCursor is defined to be a pointer to a string
>> naming the resource to load.
>> Some win32 functions defined to accept named resources will also accept
>> an integer resource identifier packed into the low word of this pointer
>> like #$IDC_ARROW.
>> I understand that it doesn't make sense to serialize the
>> value of a foreign pointer but in this case the value is really a
>> constant rather than a real pointer to some address.
>> Is there some general way to convey this fact to the compiler?
>> Cheers,
>> Matt
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel

More information about the Openmcl-devel mailing list