[Openmcl-devel] macptrs and fasl file
matt at mclaus.com
Wed Oct 7 22:55:00 EDT 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
> have their type changed to "dead-macptr".) Those limits are somewhat
> but it's pretty unlikely that addresses in the high or low ends of the
> 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
> object when the lisp MACPTR object becomes garbage. It wouldn't make
> much sense to try to serialize a GCable pointer (but it probably
> make much sense to create a GCable pointer to the high or low ends of
> 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
> On Wed, 7 Oct 2009, Matt Claus wrote:
>> 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
>> ? (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?
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
More information about the Openmcl-devel