[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.
Regards,
Matt
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