[Haskell-cafe] External representation of GHC bytecode

[Sean Seefried]

Thanks Luite,

You've obviously looked into this a lot more deeply than I have. In a
perfect world though,
wouldn't it be good for the bytecode to be platform independent?
Theoretically we know this to be
possible because the JVM has been around for a long time now. If the
bytecode could be made
to be platform independent -- and I know this would be a *lot* of work --
then we'd have a pretty good solution for Template Haskell with cross
compilers, wouldn't we?

Sean

On 9 December 2014 at 21:03, Luite Stegeman <stegeman at gmail.com> wrote:

> On Tue, Dec 9, 2014 at 5:41 AM, Sean Seefried <sean.seefried at gmail.com>
> wrote:
> >
> >
> > 1. This could solve the Template Haskell on cross compiler's dilemma.
> Currently, the problem is that a cross compiler will produce object code
> for the target machine which cannot be run on the host machine. But if this
> were bytecode the problem would be trivial to solve.
> >
>
> It still wouldn't be trivial since all kinds of platform assumptions
> are still baked into the code, for example the word size,
> sizes/alignment of foreign data types, endianness and all error
> constants in the base library. If you compile a program with the wrong
> constants you get very weird error messages and problems (I've had
> this problem). Bytecode also doesn't support certain constructs, like
> unboxed tuples, so it'd need to be extended if we wanted to run a
> whole program from bytecode.
>
> To do it properly would involve configuring packages for two different
> platforms, which would either mean supporting multiple
> versions/targets in a single GHC and package db, or a massive overhaul
> of how platform specifics are handled in libraries. Either way it'd be
> a lot more work than compiling Template Haskell code for the target
> and shipping it there to run it [1]. Eventually I'd still like to see
> multiple targets properly supported, for example for heterogeneous
> cloud haskell environments, but given the changes required in the
> Cabal and GHC, this looks like a strictly longer term option.
>
> luite
>
> [1] https://www.haskell.org/pipermail/ghc-devs/2014-December/007555.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20141209/0c50c670/attachment.html>