Re: [Liberty-eiffel] LibertyEiffel (Adler) installation fails

[Cyril ADRIAN]

Hi Christian,

2014-08-13 10:27 GMT+02:00 Christian Rinderknecht <address@hidden>:

Thank you all for your kind words and helpful hints! I managed to
install LibertyEiffel.

That's good news :-)

 

> gc/gc.h is the standard header of the BDW garbage collector. AFAIR

> you need at least a version 7.2. [...]

Is BDW used by default?

For some tools, yes. But the core compiler is compiled without GC.

 

I am assessing whether LibertyEiffel can be used for a small factor
system (think 32-bit, 64K of heap).

Has anybody trod a similar trail?

AFAIR there is some work done, and a lot more to do, to efficiently manage low-memory systems. 64K is *very* low :-)

I generate the C code with

compile_to_c -no_split -boost -gc_info foo.e

and I then patch foo.h so FSOC_SIZE and RSOC_SIZE are set to a lower
value, and I force LITTLE_ENDIAN on BYTE_ORDER.

Those constants are used by the (default) native garbage collector, not BDW.

Instead of forcing LITTLE_ENDIAN please provide a patch that correctly detects your system.

My problem has to do with I/O (the other concern being the GC).

As soon as I use the class IO (io.put_string, io.put_new_line etc.),
the GC information shows that the classes STRING and
NATIVE_ARRAY[CHARACTER] start to steadily grow (and overcome the
actual logical, useful, content). I tried calling io.flush, to no
avail. Ideally, since I try to work on an embedded system, I would
rather have very small I/O buffer, if any at all.

Any idea?

That is strange. How does your program behave without a garbage collector (passing the -no_gc option)? On such low-end systems it may be better to be memory-conservative instead of relying on the GC.

By the way, if BDW is used by default, should I expect space leaks in
theory/practice?

BDW is not the default. To use it you must pass the -bdw_gc option.

Cheers,

Cyril