[Ecls-list] ECL_FOREIGN_DATA_P(), ecl_foreign_data_pointer_safe(), etc

[Juan Jose Garcia-Ripoll]

On Tue, Oct 2, 2012 at 1:14 PM, Matthew Mondor <mm_lists at pulsar-zone.net>wrote:

> I noticed many calls to ecl_to_pointer() expanding to
> ecl_foreign_data_pointer_safe() calls even with (optimize (safety 0)).
> But interestingly in cmp/sysfun.lsp, I saw the following line:
>
> (def-inline si:foreign-data-p :always (t) :bool
> "@0;ECL_FOREIGN_DATA_P(#0)")
>

Note the "-p". This is a type predicate, which only checks whether a lisp
object contains a pointer or not.

ecl_to_pointer() is a C macro and expands to the *_safe version internally.
C compilation is not conditioned by lisp proclamations.

I also noticed that my DECLAIM to inline the accessor functions do not
> appear to work, so there also always are function calls made to
> access/set structure fields no matter the SPEED/SAFETY level.  This is
> not terrible, although if such small functions could be inlined it'd be
> nice.  Since the inline declamations appeared to work in other contexts
> for small functions, I wondered if perhaps it's a limitation of
> functions using C-INLINE.


The thing is that ECL does not keep code across compilations and not even
in compiled images. This means that the INLINE declaration is not useful
right now outside the same file (but even then, I am not sure when it is
active. I would have to look it up)


>  I also thought about perhaps generating small C functions with the inline
> directive via CLINES instead of using C-INLINE too, which could be another
> approach (I'd also have to check how to get those to register CL symbols
> and be ECL friendly then).


When I really want to inline something portably I use compiler macros.
DEFINE-COMPILER-MACRO allows you to define more precisely the expansion you
want and is the mechanism used by ECL's optimizer right now.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20121002/59d19fae/attachment.html>