GitLab

Currently Zebu throws an error, but I suspect this is due to
a bug in the underlying `mu-client-ghc-api` library.

-> Created module header stubs
-> Fixed type/API bugs

This is to make it work with global cells, which cannot be treated
as refs. Potentially this will influence performance since the GC
needs to figure out whether the thing being referenced is a heap
object etc. Yi assures me this doesn't apply to Zebu.

TODO: fix issues around top-level things being double-indirected
through the global cells.

This involved fixing a lot of the closure code, since it was
revealed that two closures may share an info table.

There's a lot to fix, but there's enough of a skeleton in place,
and code that is obviously wrong is marked with FIXME. This
branch is now ready to merge.

So far we are sketching out a skeleton for these functions that
type-checks with the new closure representation -- FIXME comments
point out where we e.g. write incorrect metadata to the closures.

The end goal for this branch is to have FromSTG compile. This will
involve fixing all static closures to use the new representation,
as well as incorporating type information into all bindings and
function calls.

Also we should fix mkClosure' to use the new
representation before merging.

i.e. whether it is a pointer, int or double

As per the last plenary meeting, we have determined that we can
statically know the Mu type of each closure, whether generated at
compile-time or run-time. As such, we can make all closures structs.
This eliminates a level of indirection to access fvs.

Note: This commit only affects CodeGen - FromSTG still needs
to be fixed to use new closures. (Which means compilation fails at
present, but Mu.CodeGen compiles by itself.)

-> Info tables are now behind an indirection;
-> Info tables are now differentiated via prefix rule,
   preserving uniform closures while allowing different
   types for the info table entries.

The main issue here is that, as per the following:

https://ghc.haskell.org/trac/ghc/browser/includes/rts/storage/InfoTables.h

different types of closured contain different info table entries. We can
*almost* get away with just hvaing a single "type-specific" field (tagref64),
but unfortunately function closures require an arity, SRT pointer and
potentially a "function type". (Although we are unlikely to use the latter
since Mu's function signatures are quite strict, making "fast" entry points
ineffective.)

e.g. an `id` function.. we have a long way to go..

Specifically, there was a bug in closure generation where the
output of a NewHybrid (ref) was passed into a GetElemIref
(which needs an iref).

Also changed `main` to print top-level definitions (i.e. haskell
closures implemented as global cells) for debugging.

This just changes them from pointing to Nathan's home directory to
pointing to mine. Ideally we can find a way to get rid of them
entirely.