[Ecls-list] ECL generates huge C file.

[Waldek Hebisch]

Juan Jose Garcia-Ripoll wrote:
> On Fri, Feb 13, 2009 at 5:46 AM, Waldek Hebisch
> <hebisch at math.uni.wroc.pl> wrote:
> > I have now created new, hopefully safe macro giving faster indirect
> > calls.  This macro works fine in the benchmark.  However in one of
> > my real files it causes huge increase in size of generated C file
> > and consequently C compiler is no longer able to compile the file.
> 
> Your file contains a lot of recursion. Every SPADCALL statement takes
> as input one or more SPADCALL statement and so on and so forth. If
> instead of a single function call, which is the commented out version,
> you now replace a SPADCALL by an IF statement, that means every node
> of the call tree gets multiplied by 2. Due to the recursivity, if
> SPADCALL calls a SPADCALL, that means 2*2, and so on and so forth,
> until I presume you get a factor 2^8 in some of the code branches.
> 
> This version does what you want without the exponential growth
> 

Yes, this works, thanks.  BTW using new version of SPADCALL
macro FriCAS is about 8-10% faster.  Unfortunatly object
files compiled using new macro are about 20% larger and
compilation of Lisp files also takes longer(about 20 - 30%).
I am not sure if I like the tradeoff...

Let me mention that I hit another (minor) problem: ffi:c-inline
whith more than 10 argument seem to silently produce wrong C
code.  More precisely, compiling the following:

(defmacro ECLCALL10(f x1 x2 x3 x4 x5 x6 x7 x8 x9 x10)
   `(ffi:c-inline (,f ,x1 ,x2 ,x3 ,x4 ,x5 ,x6 ,x7 ,x8 ,x9 ,x10)
                  (FFI:OBJECT
                  FFI:OBJECT FFI:OBJECT FFI:OBJECT FFI:OBJECT
                  FFI:OBJECT FFI:OBJECT FFI:OBJECT FFI:OBJECT
                  FFI:OBJECT FFI:OBJECT)
                  FFI:OBJECT
                  "(*((#0)->cfun.entry))(#1, #2, #3, #4, #5, #6, #7, #8, #9, #10)"
                  :one-liner t))

(defun foo(f)
    (ECLCALL10 f 1 2 3 4 5 6 7 8 9 10))

gives error because #10 is literally copied to the resulting C code.
 

-- 
                              Waldek Hebisch
hebisch at math.uni.wroc.pl