[armedbear-devel] IRONCLAD cannot be compiled on ABCL now

Chun Tian (binghe) binghe.lisp at gmail.com
Fri Jul 8 11:49:25 UTC 2011


Hi, Mark

Thanks very much. I've checked, IRONCLAD now compile well on latest ABCL.

And I also checked the compilation results, I unzipped the resulting .abcl file and see something like this:

(DEFCONSTANT +C-EVEN+ (IF (BOUNDP '+C-EVEN+) (SYMBOL-VALUE '+C-EVEN+) #2A((404250648 589532195 3334881222 3907553256 2273781383 3099122360 16843777 1330585935 909563958 2795938470 3537006546 4126536693 2038036857 1869586799 2442231441 1381127506 1616944480 3166489276 2610648731 2391671438 2745415331 202125324 2071720315 892720181 488469533 3772819424 3621223383 3267506114 774813742 1263219019 4278116350 1465336151 353719317 2004337015 926407735 3857036261 2678015647 4042319856 1246377290 3671740378 1482194264 3385394121 690594857 168437770 2981232305 2694888096 1802219883 2240097925 3183333053 ...

This means the #. reader macro has been successfully processed into literal array, this is just good.

Regards,

Chun Tian (binghe)

在 2011-7-8,16:52, Mark Evenson 写道:

> On 7/7/11 12:32 , Mark Evenson wrote:
>> On 7/7/11 11:07 AM, Chun Tian (binghe) wrote:
>>> (defconstant a #.(make-array '(8 256) :element-type '(unsigned-byte
>>> 32) :initial-element 0))
>> 
>> Reproduced and filed [as ticket #156][1]
>> 
>> [1]: http://trac.common-lisp.net/armedbear/ticket/156
>> 
> 
> [r13380][1] addresses this ticket allowing the form to be compiled again.
> 
> [r13380]: http://trac.common-lisp.net/armedbear/changeset/13380
> 
> But the compilation of the form probably doesn't do what you want.  The ABCL compiler currently dumps such forms in their READ form to be read at load time rather than constructing JVM code to initialize the value.  This has two consequences for your usage here:  first, since the string has to be derserialized by the Lisp reader there is almost no conceivable JVM implementation that will make this usage faster.  And the potentially more serious problem is that since the Lisp reader syntax doesn't specify the underlying array type, at runtime one gets an array who's BASE-ELEMENT-TYPE is T rather than (UNSIGNED-BYTE 32) which is probably less efficient.
> 
> Does anyone know if ANSI requires us to restore the compiled type at runtime?   Or is the requirement to have "at least" the type specified in the MAKE-ARRAY call?
> 
> @Alan:  I value your intuition that the sharpsign dot form here isn't portable.  But is there a specific part of CLHS that you are thinking about here that I could pore over?
> 
> 
> 
> -- 
> "A screaming comes across the sky.  It has happened before, but there
> is nothing to compare to it now."
> 
> _______________________________________________
> armedbear-devel mailing list
> armedbear-devel at common-lisp.net
> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel





More information about the armedbear-devel mailing list