Announcements, discussion openers, technical questions about the functional programming language Haskell

Tore Lund | 2 Apr 2001 15:15

Re: A Hugs bytecode interpreter

Malcolm Wallace wrote:
> 
> > There is nhc98, of course, but it is somewhat bulky for the purposes I
> > have in mind.  I am looking for something small that would compile to
> > 16-bit code that would run in 64K code + 64K data.
> 
> It's a shame that nhc98 doesn't fit your requirements, since it is
> specifically designed for creating small-memory-footprint programs.
> But as far as I know, Hugs is the only Haskell system that can produce
> 16-bit code.

Thanks for your info.  Do you know roughly how small nhc98 can get? 
Even if a 16-bit system is impossible, having a small 32-bit Haskell
could be of interest in other connections.

And is it absolutely impossible to make a 16-bit nch98?  After all, the
compiler could remain 32-bit - it's just the bytecode interpreter that
would have to be 16-bit.  A rudimentary system might suffice as long as
there is a good FFI.

And a somewhat unrelated question: is nhc98 going to have native code
generation in the foreseeable future?
--

-- 
    Tore

headers

Malcolm Wallace | 2 Apr 2001 17:25

Re: A Hugs bytecode interpreter

> Do you know roughly how small nhc98 can get? 
> Even if a 16-bit system is impossible, having a small 32-bit Haskell
> could be of interest in other connections.

The executable for a "hello world" type program currently comes out
at about 115kb code size when compiled with nhc98.  We have done
some tests on manually stripping the excess dead weight from that (by
removing class overloading, simplifying the error-handling, cutting
out big Integers, etc. etc.), and ended up with a 45kb executable.
Most of that is the bytecode interpreter itself, so it can't be reduced
much further - although we did once toy with the idea of automatically
removing code from the interpreter for individual bytecodes that were
discovered not to be used in a particular program...  

For runtime memory usage, nhc98 uses a default 20kb stack, and a
default 400kb heap, but both of these are configurable.  (There are
some other small static tables, of typically 1-2kb each.)  The absolute
minimum heap size possible is 2512 bytes - and I have some non-trivial
programs that run happily in that tiny heap (including one that runs
for over 60 seconds and writes a complex 44Mb output file!).

> And is it absolutely impossible to make a 16-bit nch98?  After all, the
> compiler could remain 32-bit - it's just the bytecode interpreter that
> would have to be 16-bit.  A rudimentary system might suffice as long as
> there is a good FFI.

It should be quite possible, yes.  At a guess, the main change
needed is to adjust some hard-coded constants to determine the size
of ints, addresses, and alignment boundaries.  Provided you have a C
cross-compiler for the 16-bit machine, that should be all you need.

(Continue reading)

headers

Tore Lund | 3 Apr 2001 11:15

Re: A Hugs bytecode interpreter

Malcolm Wallace wrote:
> 
> > Do you know roughly how small nhc98 can get?
> > Even if a 16-bit system is impossible, having a small 32-bit Haskell
> > could be of interest in other connections.
> 
> The executable for a "hello world" type program currently comes out
> at about 115kb code size when compiled with nhc98.  We have done
> some tests on manually stripping the excess dead weight from that (by
> removing class overloading, simplifying the error-handling, cutting
> out big Integers, etc. etc.), and ended up with a 45kb executable.

Okay.  Now, if those 45K consist of e.g. 40K code (or "text") and 5K
data, this leaves us with 24K free in the code segement and 59K minus
heap/stack in the data segment.  That should be abundant for a small
system.  In fact, if bytecode is kept in the data segment - which I
suppose it is - one would not have to pare down the code ("text") that
much.

> Provided you have a C cross-compiler for the 16-bit machine, that 
> should be all you need.

Well, I don't, so I suppose I would have to use a 16-bit compiler.  And
this probably means having to change a good deal of Unix-specific
stuff.  This is the sort of thing one would also have to do for a Win32
port, so it's not a bad form of exercise at all.  But it would probably
take a good deal of effort.

In short, I don't think I have the time or inclination at the moment to
get into nhc98 internals.  So if you are able to lend me makefiles for

(Continue reading)