low level memory progress

0 views
Skip to first unread message

Geoffrey Irving

unread,
Apr 29, 2011, 2:58:30 AM4/29/11
to duck...@googlegroups.com, Dylan Simon
Hello,

Good news: I converted the interpreter to store values in raw memory
format (no more Haskell Value algebraic datatype). All very clean
code-wise, and all the tests pass if I allocate the memory with malloc
(and then never free it).

Bad news: It crashes if I switch to the Boehm collector, and looks
like an allocated block is being overwritten. My only guess is that
the Haskell runtime system is confusing the Boehm collector somehow,
which if so is likely impossible to debug. Alas.

Geoffrey

Dylan Simon

unread,
Apr 29, 2011, 1:40:19 PM4/29/11
to Geoffrey Irving, duck...@googlegroups.com
Well, this still brings us closer to being able to use a real backend, right?

When you say malloc... if you use Foreign.Marshal.Alloc (or Foreign.StablePtr)
the memory should be exempt from haskell management, as should malloc calls
done during foreign calls. I have to admit I don't remember how all this
works, so I'll take a look at it when I can.

At the moment I can't build due to missing modules which must be dependencies
not specified in duck.cabal, so I'll deal with that end first.

From Geoffrey Irving <irv...@naml.us>, Thu, Apr 28, 2011 at 11:58:30PM -0700:

Geoffrey Irving

unread,
Apr 29, 2011, 7:28:37 PM4/29/11
to Dylan Simon, duck...@googlegroups.com
On Fri, Apr 29, 2011 at 10:40 AM, Dylan Simon <dylan-...@dylex.net> wrote:
> Well, this still brings us closer to being able to use a real backend, right?

Yep. And we can probably ignore the issue for now and use normal
malloc with no frees. Once we self-host Boehm should work fine, and
we should be able to survive until then without any garbage
collection.

LLVM is probably the way to go backend-wise, so the next step is to
figure out the easiest way to interface with it. I'm somewhat
hesitant to use the standard Haskell bindings since the eventual goal
is self-hosting, but I suppose we'll have to port everything over
anyways so my hesitancy may be misguided.

> When you say malloc... if you use Foreign.Marshal.Alloc (or Foreign.StablePtr)
> the memory should be exempt from haskell management, as should malloc calls
> done during foreign calls.  I have to admit I don't remember how all this
> works, so I'll take a look at it when I can.
>
> At the moment I can't build due to missing modules which must be dependencies
> not specified in duck.cabal, so I'll deal with that end first.

Cool.

Email note: Your client is setting Reply-To to be my name instead of
yours for some reason, so by default if I reply I reply to me and
duck...@googlegroups.com

Geoffrey

Reply all
Reply to author
Forward
0 new messages