[cmucl-imp] Unboxed float arguments

[Helmut Eller]

* Raymond Toy [2012-06-23 20:41] writes:

> On 6/23/12 11:05 AM, Helmut Eller wrote:
>> * Raymond Toy [2012-06-23 15:30] writes:
>> 
>>> So, how do I build your changes?  I assume can just do a normal
>>> cross-compile using tccxboot.lisp?
>> 
>> Yes, that's the idea.  I use the snapshot from June.  During the build
>> process you need to answer two questions:
>> 
>> 1. for the constant IR1-ATTRIBUTE-TRANSLATIONS choose "Go ahead"
>> 2. for the struct VM-SUPPORT-ROUTINES choose "CLOBBER-IT" 
>
> Yep, I just guessed that those are the answers, so I have recompiled
> cmucl with the new feature.  We'll have to fix the issue with the
> questions if possible.
>
> I also noticed that when compiling the target, I get an error:
>
> ; File: /Volumes/share2/src/clnet/cmucl/cmucl/src/compiler/dump.lisp
>
> ; In: DEFUN DUMP-CODE-OBJECT
>
> ;   (DUMP-FOP 'LISP::FOP-TYPED-ENTRY-POINT FILE)
> ; Error: (during macroexpansion)
> ;
> ; Error in function LISP::ASSERT-ERROR:
> ;    Compiler bug: LISP::FOP-TYPED-ENTRY-POINT not a legal fasload operator.
>
> Seems to be harmless, because the result can rebuild cmucl just fine.
> But we should fix this too.

Hmm, I don't see this one.

>
>> 
>> I also added a file src/tests/unboxed-convention.lisp with some examples
>> that do work.  Tho, I'm sure that there are cases left that don't work.
>
> I'll do some more tests with this a bit later.  I'd be interested in
> some bigger tests with maxima, once I hack f2cl to generate the ftype
> declarations for the translated functions.  This might tease out a few
> corner cases that you missed.  And it might give a nice speed up for
> those functions.  (Although, I think most functions are fairly long, so
> boxing and unboxing is probably in the noise, but it might save on some
> GC time.)

I worked a bit more on this and enabled the unboxed convention during
built time for all the easy cases (not for &keyword/&rest and that kind
of thing).  After fixing some bugs it seems to work good enough to
compile and load PCL.

Unsurprisingly, Genesis doesn't work yet.  I guess that we should do
some linking during cold-load but it's a bit complicated:

1. that would need some checks/verification that the types of callsites
and unboxed entry points agree, but which typesystem should be used?
The best would probably be some way to model the types that are being
loaded but that seems complicated.  Can we just use the types of the
compiler's target backend?

2. if the types don't match we usually generate adapters but that's also
not so easy during Genesis.  I guess creating a function with some fake
name, cross compiling it, and cold loading the fasl file would work.
But it also seems messy.  OTHO, I don't even know whether there are any
type mismatches.

Maybe this is just the price to pay for a meta-circular implementation,
but I'm wondering if I overlook some shortcuts.

Helmut