[Ecls-list] Outlook, ideas?

[Juan Jose Garcia-Ripoll]

Hi,

I am collecting ideas for my personal summer of code :-) Before leaving on
the 3rd of July (I will be not so reachable until the 21st) I will try to
make the last 0.9 release. Afterwards I want to work on stability and
getting the first 1.0, but that should have something special with it.

* Unicode. This seems to be en route with Brian's changes.

* Compiler fixes. I will spend at least august using Paul Dietz's random
tester to try crashing ECL in all possible ways. 1.0 will not come until we
get rid of all current compiler bugs.

* Documentation. People may help here. Nothing big is expected. It would be
enough if somebody has a look at the manuals and reorganizes them, dropping
out all information which is already in the Hyperspec, creating a section
for ECL-specific behavior, another section for extensions, incorporating the
docs about multithreading, etc.

* Interpreter. Some time ago I managed to speed up the bytecodes interpreter
and compiler by 20%. Those changes are lost (*). I would need some time, but
basically I reorganized the bytecodes, simplifying some, and adding extra
flags and two registers. Also, perhaps we should focus on a more compact
representation of bytecode functions.

* Calling conventions. This is something that I have in mind since I first
worked on ECL. The ideal goal would be to be able to call functions
directly, via a pointer, but with a portable implementation. I have been
thinking on a scheme like

struct ecl_cclosure {
    HEADER;
    cl_object (*function)(int narg, ...);
    /* data goes here */
};

All funcallable objects would have this structure and add their own fields.
Calling a funcallable objects amounts then to 1) set a global variable with
a pointer to the closure, 2) call directly the function. This avoids having
to push arguments on the stack. Functions with a fixed number of arguments
would have a similar structure

struct ecl_cfun {
    HEADER;
    cl_object (*function)(int narg, ...);
    /* data goes here */
    cl_object (*true_fun)();
    cl_object name;
}

Bytecodes would also be closures, and generic functions as well. I would
like to get feedback on this topic. My only concern is the global variable
containing the closure data. It seems like it could have a significant
overhead in multithreaded lisps. But perhaps there are tricks, like
thread-local variables, which would help. And maybe the overhead is way
smaller than current use of funcall() and the lisp stack.

Juanjo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20060619/3ba98114/attachment.html>