[mercury-users] a theoretical problem

Thomas Conway conway at mds.rmit.edu.au
Mon Apr 28 11:40:00 AEST 2003

On Friday 25 April 2003 03:10, Fergus Henderson wrote:
> On 24-Apr-2003, Tom Wouters <tom.wouters1 at student.kuleuven.ac.be> wrote:
> > We're working on our thesis -it's about using logic programming for
> > robot-control- and we would like some insights on why it would, or
> > wouldn't be possible to run Mercury on an embedded processor wich only
> > has about 16Kbyte of memory available.
> Was that 16K RAM, 16K ROM, or 16K total?
> I think it would most likely be possible to run some Mercury programs on
> such a system, with a few caveats.  The first major caveat is that the
> garbage collection is not likely to be usable in such an environment.
> The second caveat is that getting it all working would probably require
> a lot of effort.  The third caveat is that although you can probably
> squeeze Mercury to fit in 16K, with a lot of effort, once you've done so I
> think you won't have any space left over to do anything useful.  (If your
> embedded processor had 32k or 64k, that would make it a lot easier.)

One thing that I've thought of doing for a long time is to add analysis on top
of the current termination analysis to allow the compiler to estimate an upper 
bound of the number of cells allocated by a predicate. For applications like 
an embedded controller, which are typically interrupt driven this could 
eliminate the need for GC altogether.

The idea goes like this:
	1. add pragmas that will trigger a compile time error if more than <N>
	cells can be allocated by this predicate.
	2. set <N> to be small enough for your memory (e.g. 4K).
	3. have "special storage" reserved for values that must survive between
	4. each interrupt is handled by running a handler predicate which is
	constrained by said pragmas in how much memory it can use. On
	completion, it copies its results in to the special storage and the heap
	is truncated ready for the next interrupt.

I'd really like to make a MIDI wind instrument with a Mercury programmed 
controller in it that takes the presses and releases of switches on the 
instrument and converts them into a stream of midi events (many embedded 
controllers have RS232/RS442/USB on them). :-)

I assume you've read the "Lambdas in the Liftshaft" paper about embedded 
systems with lazy functional programming.
Dr Thomas Conway                            Multimedia Database Systems, RMIT
<conway at mds.rmit.edu.au>      499 User Error: Replace user and press ANY key.

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

More information about the users mailing list