[Ecls-list] ECL cross-compilation

[Juan Jose Garcia Ripoll]

On Tuesday 22 July 2003 13:25, Eugene Zaikonnikov wrote:
> Hello,
>
> I am trying to port ECL to Agenda VR3. It runs Linux 2.4.0, XFree86
> 4.0 and has 8M RAM + 16M flash storage. The issue is complicated by
> the fact that I am a total newbie in ECL and cross-compilation :)

Nice project! I was toying with the idea of porting ECL to a Palm myself -- 
lack of time and compilation tools, and a palm prevented it though.

> A quick glance into src/configure gives an impression that it was made
> with cross-compilation support in mind; however certain tests exit the
> process if attempted during cross compiling. What is the best way to
> deal with them? Shall I just replace these tests with respective fixed
> values?

Most of "configure" can be used for cross compilation. This is because 
Autoconf takes care of building the tests, and most of them do not require 
running programs.

However, I had to write a couple of tests that need information about the 
run-time environment: they check the size of fixnums and the direction of 
growth of the stack. It should be very easy to modify configure.in adding the 
options
	--with-stack-growth=(up|down)
	--with-fixnum-type=(int|long)
	--with-fixnum-bits=# of bits in C fixnum type
Then, in aclocal.m4 one needs to add a third argument to each AC_TRY_RUN, 
providing a default value for the cross-compilation environment, which would 
be taken from the configuration options at the command line.

> Another issue is runtime/executable size. Stripped binary of freshly
> built ECL-0.9 on x86 box is about 900K, and it occupies around 4 megs
> after launch. However, in PDA environment the less is the better. Is
> there a way to make binary/runtime size even smaller? What can be
> tweaked/removed? I am willing to compromise GC efficiency, additional
> features, etc. for that.

Funny, my current benchmark gives 800k stripped, 3Mb resident size on a P6, 
which is a very inefficient architecture. Does the Palm provide a dynamically 
linked C library?

A for getting the most of the size, you can get rid of the toplevel, of the 
inspector (lsp/describe.lsp, clos/inspect.lsp), of the bytecodes disassembler 
(src/c/disassembler.d). One might also gain a lot of space using block 
compilation: all lisp sources are fed as a single file to the compiler, which 
can then produce smaller data sections (for instance, if two object files 
reference the symbol A, there is no need to keep two copies of the name of 
this symbol in two object files), and functions may call each other.

You can also think about tweaking the old garbage collector 
(src/{gbc,alloc}.c) to work with the palm. This a very small and conservative 
garbage collector without generations. The only problem with it is that it is 
not very clever at allocating memory from the system (currently, on linux, it 
uses a mmap with a fixed address), which needs to be fixed.

It should also be possible to port clossette (the CLOS implementation from the 
AMOP) to ECL. But I don't know whether this would provide a huge improvement 
in size, though.

Finally, you might consider building ECL without CLOS. That would mean having 
a look at things that, due to the ANSI-fication of ECL assume that CLOS is 
present (Mainly, the condition system).

I would like to help you on this. However, I have very strict time constraints 
at the moment: I'll be away from the 24th to the 28th, and then after the 9th 
of August I'll be hacking on the spanish beach without internet connection 
:-)

Best regards,

Juanjo