* Marco Antoniotti [2012-06-10 06:39] writes:
Cool.
I have not really looked at the code, but how generalizable would this approach be? I.e. why stop at FTYPEd floats?
For named calls we could delay some decisions to link-time. At link time we know more about the entry-point/callee and don't need to be quite so conservative. E.g. we could perform the argument count check only at link time and then skip it at runtime. Also optional/keyword parsing could be avoided or at least be more efficient. If we can patch all callsites we could also use direct calls instead of indirect calls (though that would probably be problematic GC-wise). It might also be useful for generic functions, e.g. if the static type of a call-site determines a unique method we could link the two directly. We can't easily change the representations that are used immediately before the callsite, though. E.g. situations like this are problematic: (declaim (ftype (function (double-float) double-float) f)) (defun g () (f 1)) (declaim (ftype (function (number) number) f)) (defun h () (f 1)) Although G and H look the same, in G execution will never reach the callsite because at compile-time we have committed to unboxed double-float representation. Since there is no way to convert an integer to an unboxed double-float we will generate code that signals an error before the call. In H we choose boxed representation and the call works just fine. I think the link-time tricks are quite neat, but what really matters are representation choices and those have to be made at compile-time. Therefore I focus on (trustworthy) ftype declarations.
I am asking because of Pascal Costanza's recent post on the PRO mailing list about stack-allocation of values (a DYNAMIC-EXTENT on steroids)
I don't know the details of that message, but stack-allocation is also a kind of representation choice. To make it work efficiently we'd also need to make assumptions and choices at compile time. If those assumptions turn out to be wrong, linker tricks will probably not suffice. I guess a JIT compiler with deoptimization support is needed for the hard cases. Helmut