[mercury-users] a theoretical problem

[Pieter Laeremans]

Fergus Henderson writes:
 > On 24-Apr-2003, Tom Wouters <tom.wouters1 at student.kuleuven.ac.be> wrote:

First of all thanks very much for this reply !
 > 
 > > We first tought mayby a stripped-down version of the language might 
 > > produce a runtime small enough to fit in the memory, but we don't realy 
 > > have a good idea how small the runtime could get (since terminal-io libs 
 > > etc aren't nescesairy) without losing the power of backtracking etc.
 > 
 > With the `--high-level-code' back-end, there's almost no need for a
 > runtime system at all -- for example, I can run the N-queens program
 > from tests/benchmarks/queens.m in the "hlc.gc" grade using a 128-byte
 > runtime and standard library, plus the Boehm collector, plus the C
 > standard library.  See the attached "tiny_runtime.c" file.
 > 
 > 128-bytes, fantastic!  That will fit in 16K no problem.  However, that's
 > only half the story.  Of course the problem is that the Boehm collector
 > and the C library are a lot bigger than 128 bytes.
 > 

Yes it is :-). But when I compile it's size is 's 1.2K.

When I compile tiny_runtime.c  with :

gcc -c -I/usr/local/mercury-0.11.0/lib/mercury/inc/ tiny_runtime.c


Then I try to link it the queens.o genereated by mmc.

gcc -Wl,--gc-sections queens.o tiny_runtime.o -lgc -o test
queens.o(.rodata+0x88): undefined reference to `MR_grade_v8_hlc_gc_tags2'
collect2: ld returned 1 exit status


I ve copied the mercury_grade.c file to the local directory because it
was included.

 > Using the "hlc" grade, and a slightly more complicated runtime -- see
 > the attached "tiny_runtime2.c" file -- avoids the need to link in the
 > Boehm collector.  This runtime is still less than 300 bytes, but now
 > we need to also link in a few of the files from the original Mercury
 > runtime directory (mercury_engine.o, mercury_thread.o, mercury_memory.o,
 > mercury_memory_zones.o, mercury_memory_handlers.o, and mercury_context.o)
 > for initializing the Mercury heap.  These use about 8k of code space,
 > most of which could probably eliminated by only including the parts
 > which are really needed (I didn't try that) and about 5k of data space,
 > most of which is not actually used (it can be reduced to about 1k
 > by changing the setting of MR_MAX_VIRTUAL_REG).  If you want to have
 > all of that, plus the relevant parts of the C library, plus some space
 > for a Mercury heap, then more optimization is needed before this will
 > fit into 16k.  But it is not too far off.
 > 

I guess there 's something wrong with my mercury installation.
Compiling in the hlc grade doesn't work.

I get:

mmc --compile-to-c --grade hlc          queens > queens.err 2>&1
mgnuc --grade hlc        --      -c queens.c -o queens.o
queens.c:22: assoc_list.mih: No such file or directory
queens.c:23: bool.mih: No such file or directory
queens.c:24: builtin.mih: No such file or directory
queens.c:25: char.mih: No such file or directory
queens.c:26: deconstruct.mih: No such file or directory
queens.c:27: enum.mih: No such file or directory
queens.c:28: int.mih: No such file or directory
queens.c:29: io.mih: No such file or directory
queens.c:30: list.mih: No such file or directory
queens.c:31: map.mih: No such file or directory
queens.c:32: ops.mih: No such file or directory
queens.c:33: private_builtin.mih: No such file or directory
queens.c:34: set.mih: No such file or directory
queens.c:35: std_util.mih: No such file or directory
queens.c:36: string.mih: No such file or directory
queens.c:37: term.mih: No such file or directory
queens.c:38: time.mih: No such file or directory
queens.c:39: tree234.mih: No such file or directory
queens.c:40: type_desc.mih: No such file or directory
make: *** [queens.o] Error 1


There isn't a directory for the hlc grade. Is this normal ?  Should I
compile mercury again ?

$ ls /usr/local/mercury-0.11.0/lib/mercury/lib/
asm_fast.gc          asm_fast.gc.prof      asm_fast.gc.tr        hlc.gc      i686-pc-linux-gnu
asm_fast.gc.memprof  asm_fast.gc.profdeep  asm_fast.gc.tr.debug  hlc.par.gc  


 > Even with the older `--no-high-level-code' back-end, the runtime
 > system could be made pretty small; all it really needs to do is
 > initialize the memory areas (heap, stacks, etc.)
 > I've also attached another file "tiny_runtime3.c" which works
 > in grade "asm_fast".  This needs to link in the same Mercury
 > runtime files as above, plus mercury_dummy.o and mercury_reg_workarounds.o.
 > The sizes are similar to the "hlc" grade, although I think the "hlc"
 > grade has more scope for improvement here than the "asm_fast" grade.
 > 
 > > So the actual question is how would you guys tackle the problem,
 > > and why would(n't) it be possible to run Mercury directly on the 
 > > embedded processor?
 > 
 > Firstly, compile everything with -ffunctions-sections -fdata-sections
 > in CFLAGS (this requires a moderately recent version of GCC)
 > and link with -Wl,--gc-sections (this requires a moderately recent
 > version of GNU binutils).  This should avoid dragging in a lot of
 > unnecessary code.
 > 

Why those -ffunctions-sections ?  From the gcc documentation I get :

"When you specify these options, the assembler and
     linker will create larger object and executable files and will
     also be slower."

This seems undiserable in an embedded environment so I'm not getting
something.   Or in case the --gc-sections occur at compile time I
guess it could be beneficial.


thanks in advance,

Pieter
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------