headers
Tore Lund | 1 Apr 2001 16:46
Picon
Picon

A Hugs bytecode interpreter

Hugs is a neat system, but the very idea of compiling from source code
each time you run a program makes Hugs unsuited for many purposes.  So
my question is, has anyone tried to rearrange the components of Hugs
into a bytecode compiler plus runtime?  And if not, maybe the Hugs
maintainers had a word of advice on how to go about this?

There is nch98, 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.  The raw material for
such a system is probably present in Hugs, but what's the best way to
extract it with a minimum of fuss?

Grateful for any hint.
--

-- 
    Tore
Permalink | Reply | 4 comments |
headers
andrew | 1 Apr 2001 18:58
Picon

Multiple modules in a file

Hi,

I don't seem to be able have multiple modules in one file (at least
for hugs and ghc).  The gentle intro says that there is no restriction
and I can't find any mention in the ghc jobs (apart from a
recommendation to name a file after the module it contains to help
make).

It's not a desperate problem - I can split files - but I'd like to
know if I'm doing something stupid, or if this is a real restriction.
(I can see arguments why from an engineering/maintenance point of
view, but one module is small and fits nicely with another; it also
makes literate programming slightly more complicated).

Thanks,
Andrew

--

-- 
http://www.andrewcooke.free-online.co.uk/index.html
Permalink | Reply | 1 comment |
headers
luc | 1 Apr 2001 22:52

[Fwd: beginners silly question : apologies and lib question]
From: luc <ltaesch <at> europemail.com>
Subject: Re: beginners silly question : apologies and lib question
Date: 2001-04-01 20:48:33 GMT
last week , i had some issues about ghc install on win.
since i found the win install page on ghc page, which i followed, and it now
works. so apologies for whining too early.

can i have libs in the same directory dor both ghc and hugs ?
or are there incompatiblities ?

mentionnaing that, i havent found how to setup lib path in ghc in the user man.
any  variable, or command line options ?

Luc taecsh wrote:

> 3)if i get some good stuff done, id like to compile them , as small
> utilitaries. (best way to turn H in my daily job)
> my first try at ghc was not that fun (deppendencies on gcc, libs, and so on)
> as a alternative, ive tried under linux (m7.2),where ghc is installed by
> default, but even here , were i was expecting fluentness, its not cristal
> clear,  hangs, missing bits i dont understand. no samples/ demo ? or is it a
> packaging issue ?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Malcolm Wallace | 2 Apr 2001 12:31
Picon

Re: A Hugs bytecode interpreter

> 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.

> So my question is, has anyone tried to rearrange the components of
> Hugs into a bytecode compiler plus runtime?

The predecessor of Hugs was Gofer, which was supplied with a variant
called Gofcc that produced standalone bytecodes, just as you desire.
Gofer was very like Haskell 1.2.  It is still available by FTP:

    http://www.cse.ogi.edu/~mpj/goferarc/index.html

Many years ago for my PhD work, I modified Gofer/Gofcc to create
standalone programs to run on an embedded system.  The resulting a.out
program had to be encoded into S-records and downloaded to the board
via a serial cable.  Back then, I was targeting a 32-bit processor
(M68000), but Gofer was equally capable of producing 16-bit code.
As I recall, my most complex example (a liftshaft control program,
attached to a real physical liftshaft made of mecchano) probably needed
around 250Kb of memory in total (code + heap + stack), although the
board was fitted with a generous 768Kb.

My modified version of Gofer/Gofcc is available here:
(Continue reading)

Permalink | Reply | 3 comments |
headers
Tore Lund | 2 Apr 2001 15:15
Picon
Picon

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
Permalink | Reply | 2 comments |
headers
Malcolm Wallace | 2 Apr 2001 17:25
Picon

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)

Permalink | Reply | 1 comment |
headers
Jan Skibinski | 2 Apr 2001 18:24

modules Eigensystem and LinearAlgorithms

	Experimenting recently with some quantum problems I've
	decided that it's time to add some long overdue
	algorithmic support for module QuantumVector.

	So here are two new modules added to our collection:
	http://www.numeric-quest.com/haskell/LinearAlgorithms.hs
	http://www.numeric-quest.com/haskell/Eigensystem.hs

	The former partially overlaps with module Orthogonals,
	but their most important algorithms are different,
	although both modules use lists for representation
	of matrices. This is still work in progress, but usable
	as it is for Hermitian matrices.

	Both modules are thoroughly documented, so here are just
	few buzzwords:

	Housholder reduction, complex reflection, Hessenberg
	matrix, similarity, triangularization, tridiagonalization,
	operators and maps.

	Jan
Permalink | Reply | 0 comments |
headers
Alastair Reid | 2 Apr 2001 20:26
Picon
Favicon

RE: ffi & recursive data types

> I'm new in ffi stuff and tools like greencard.
> Everything was working ok, until I wanted to:
>
> translate a haskell recursive data type(list,trees,etc) into
> a corresponding C type and back again.
>
> How can I do this?

If you want to see how to convert Haskell lists into arrays, look at the string support in StdDIS.gc or look at
the handling of
lists of <almost anything> in the various greencard examples out there (like the X11 support in the HGL).

If you want to convert haskell data structures to isomorphic C data structures, you want to write a C
constructor function which
will allocate and initialize an object corresponding to each Haskell constructor and then write a Haskell
function which will copy
the data structure from Haskell to Haskell (this is a warmup) and then convert it to copy from Haskell to C.

And to convert back, you define functions with which to implement "pattern matching" on the C objects and
use those to modify your
copy function again.

For example:

  data T = T1 Int | T2 Int T T

->

  enum T_tag { T1, T2 }
  struct T1 { int tag; int f1 }
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alastair Reid | 2 Apr 2001 20:32
Picon
Favicon

RE: question class tree

> I need a class tree for haskell. where can i find it?

I'm interpreting this as you want a picture showing how the standard Haskell
 classes relate to each other.

And my answer is to scroll 1/4 - 1/3 of the way down this page looking for a big picture.

  http://haskell.org/onlinereport/basic.html

--
Alastair
Permalink | Reply | 0 comments |
headers
Alastair Reid | 2 Apr 2001 20:40
Picon
Favicon

RE: Multiple modules in a file

> I don't seem to be able have multiple modules in one file (at least
> for hugs and ghc). 

As far as I know, the only compiler that ever supported this was the
 Yale compiler (which is no longer maintained and probably hard to track 
 down).

The current trend is to put each module in a file by itself and, to make life
 easier for Hugs import chasing or for automatic generation of Makefile dependencies,
 to make the filename match the module name.

--
Alastair Reid
Permalink | Reply | 0 comments |

Gmane