[mercury-users] lower level use?

Fergus Henderson fjh at cs.mu.OZ.AU
Wed May 26 16:25:05 AEST 1999


On 23-May-1999, Rob <zharradan at suffering.org> wrote:
> I was just marvelling at what people are doing these days with software
> - an extremely functional emulator for the Sony Playstation has just
> been released (www.bleem.com, if anyone cares). This got me thinking..
> obviously these sorts of things will be written in C, as it seems like
> the type of task C was made for; it's all very low level, dealing with a
> foreign instruction set and translating it. I was just wondering though,
> could this sort of thing be done with Mercury, possibly making the code
> much neater, and nice and functional?
>
> Has anyone tried any (most likely much smaller scale) projects of this
> sort before, perhaps?

I have put a fair bit of effort into making it possible to write efficient
interpreters in Mercury.  Writing machine emulators is quite similar, so I
think it should be possible to write something like that in Mercury.
However, the only way to really be sure is to do it.

The main problem with doing this kind of thing in a declarative language
like Mercury is that when writing efficient interpreters and machine
emulators, you really need an efficient way of accessing and destructively
modifying memory at a fairly low level -- some kind of abstraction that
is similar in essence to pointers in C.  Goedel, which was one of the
languages that strongly influenced Mercury, lacked such a facility, and
as a result, it was not possible to write efficient interpreters in
Goedel.  (Haskell as defined by the Haskell report also lacks that kind
of thing, although I think most Haskell implementations to provide some
way of doing it.)  But in Mercury you can use the `store' module in
the standard library to model the memory of the machine that you are
emulating, or to store the environment (the variable name to value mapping)
for your interpreter.

Corin Gurr did some quite good work on partial evaluation of Goedel programs.
One of the nifty ideas with partial evaluation is to take an interpreter,
and specialize it with respect to a particular program, thus giving you
a compiled version of the program.  If you have a self-applicable
partial evaluator, then you can automatically generate a compiler from
an interpreter!  Unfortunately if you do this in a language which
doesn't provide the facilities that you need in order to write
efficient interpreters, then making the end result efficient is very
difficult.  The results that Corin Gurr and the other researchers
working on Goedel obtained from partial evaluation thus unfortunately
included some abysmal performance results.

My hypothesis is that with use of the `store' module, and other
features of Mercury which can improve performance, it would be
possible to do much better.  But as yet we haven't done the experiment.
This might make an interesting project for someone...

Cheers,
	Fergus.

P.S.
Another item on my list of "things to do in the unlikely event that I ever
get time" is a port of Mercury to the PalmPilot.
That's another one which might make an interesting project for someone.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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