[Ecls-list] function_dispatch

[Matthew Mondor]

Since a previous message I sent with text/plain attachments never made
it to the list, I resend it but instead provide a link to an archive
with the three files:

On Sun, 24 Jan 2010 11:33:55 +0100
Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com> wrote:

> Sure! Just for the record, the proxy you are mentioning is this one
>   cl_objectfn ecl_function_dispatch(cl_env_ptr env, cl_object x)
> This function takes a lisp object and returns a directly callable C function
> pointer. This was a great optimization compared to the previous code that
> would take all the arguments, the function object and perform a huge
> dispatch that took a lot of time.
> 
> ecl_function_dispatch() is therefore used when we want to call a function
> and do not have or do not want its C function pointer. This happens for low
> optimization settings, generic functions, closures, interpreted functions
> and in general functions that have been defined in a separate file.
> 
> Without ecl_function_dispatch() the C address of a function is hard-coded in
> the caller and thus the callee can not be redefined. It can thus be avoided
> only when debug optimization settings are low and the function is defined in
> the same file -- or it is a function that is know not to be redefinable, as
> those in the COMMON-LISP package.
> 
> I would thus be very much interested in knowing under which circumstances
> you have experienced the change, with perhaps a minimal example and the
> version of ECL (9.8.3?)

Thanks for the explanation :)
The test code I was playing with when I noticed the change between
9.8.3 and 10.1.1 was:

http://ftp.pulsar-zone.net/tmp/ecl-msg-test.tgz
(contains the small lisp file along with objdump -dS results files).

An especially short function 9.8.3 generated was message-reply which
is indeed a very small function, but which gets expanded far more in
10.1.1.

I didn't realize, but it makes sense as you said, that if functions can
be redefined, the caller should probably not hardcode the address,
except for functions expected to remain static (or at the request of
the application builder).

I'm still able to generate static calls being used after using
compile-file with (declaim (optimize (speed 3) (safety 1) (debug 1)))
at top of the file.

When I have more time I'll probably experiment with the various
situations you described which affect the decision on if dynamic or
static function dispatch is generated, so that I can more easily
generate static code for performance-critical paths while also taking
advantage of CL dynamic features in other areas...

Thanks again,
-- 
Matt