Haskell/GHC port?

[Richard W.M. Jones]

Has anyone looked at porting GHC to RISC-V? Google turns up
very little ...

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

[Karel Gardas]

On Sat, Oct 22, 2016 at 8:42 AM, Richard W.M. Jones <rjo...@redhat.com> wrote:
>
> Has anyone looked at porting GHC to RISC-V? Google turns up
> very little ...

The question is if LLVM is enough ready. GHC is quite a beast and
although it supports cross-compilation it is always better to use
native-compilation to be able to run testsuite. Hence question of how
emulators are fast or how the fastest hardware available is fast...

Cheers,
Karel

[Karel Gardas]

Well, LLVM doesn't need to be ready at the moment since first step may
be to get GHC unregisterised build working. This is a build where GHC
will use its C backend to generate C code and C compiler to compile
it. Generally speaking such build is even slower so the case of highly
performance emulator or board is even more critical. For example I've
attempted to do build GHC on SPARC/Linux running in Qemu on top of
Solaris 11 running on SB E5-2620 and after IIRC 2 weeks of run where
I've been around half of the build IIRC I've given up. And SPARC/Linux
is also using unregisterised kind of build... But this was 1-2 years
ago so I'm not sure if Qemu got any faster in the meantime...

[Richard W.M. Jones]

For the record we are building everything natively inside QEMU on
Intel Xeons and while not blazingly fast, it's fast enough. There is
no cross-compilation involved.

The main drawback is that QEMU is single threaded, so while we can do
16 builds in parallel, we can't do a single build 16 times faster.

To give you some idea of the speed of emulation, here is how long it
took to build some popular packages:

Package Time (secs)
boost 115910 32 hours
cmake 58277 16 hours
gcc 310508 86 hours (3.5 days)
glibc 43021 12 hours
python2 20438 6 hours
python3 26084 7 hours
ruby 20423 6 hours
systemd 69088 19 hours
xemacs 22178 6 hours

I was really asking if anyone had gone through the process of
porting/bootstrapping GHC. I'm not especially interested in doing
that myself, but it is the second most popular dependency that is not
yet built in Fedora (after the JDK).

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com

virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html

[Ben Gamari]

On Saturday, October 22, 2016 at 5:44:45 AM UTC-4, gardask wrote:

On Sat, Oct 22, 2016 at 11:26 AM, Karel Gardas <gar...@gmail.com> wrote:
> On Sat, Oct 22, 2016 at 8:42 AM, Richard W.M. Jones <rjo...@redhat.com> wrote:
>>
>> Has anyone looked at porting GHC to RISC-V?  Google turns up
>> very little ...
>

I actually looked at this last weekend and have some LLVM [1] and GHC [2] patches which I'm waiting to test but I suspect a long debugging session will ensue when this happens. Unfortunately after spending an hour on the patches themselves I spent the rest of the weekend going down a rabbit-hole trying to bring up a riscv toolchain in Nix. This lead to [3] which sadly doesn't quite work yet due to toolchain incompatibilities (the kernel tree I found still seems to refer to the stime CSR whereas it has already been removed from my toolchain). This should all get much easier when the binutils and gcc ports are upstreamed.

> The question is if LLVM is enough ready. GHC is quite a beast and
> although it supports cross-compilation it is always better to use
> native-compilation to be able to run testsuite. Hence question of how
> emulators are fast or how the fastest hardware available is fast...

Well, LLVM doesn't need to be ready at the moment since first step may
be to get GHC unregisterised build working.

I was able to prepare an unregisterised stage1 cross-compiler inside of sbate's Docker image without much trouble on Friday. The "hello world" executable that it produced ran successfully on the emulator.

Cheers,

- Ben


[1] https://github.com/bgamari/llvm/tree/riscv-trunk-ghc
[2] https://github.com/bgamari/ghc/tree/riscv
[3] https://github.com/bgamari/riscv.nix
[4] https://github.com/sbates130272/docker-riscv/blob/master/Dockerfile

[Stefan O'Rear]

On Tue, Nov 1, 2016 at 10:48 AM, Ben Gamari <bga...@gmail.com> wrote:
> I actually looked at this last weekend and have some LLVM [1] and GHC [2]
> patches which I'm waiting to test but I suspect a long debugging session
> will ensue when this happens. Unfortunately after spending an hour on the
> patches themselves I spent the rest of the weekend going down a rabbit-hole
> trying to bring up a riscv toolchain in Nix. This lead to [3] which sadly
> doesn't quite work yet due to toolchain incompatibilities (the kernel tree I
> found still seems to refer to the stime CSR whereas it has already been
> removed from my toolchain). This should all get much easier when the
> binutils and gcc ports are upstreamed.

We discussed this a bit on IRC but the binutils have moved past 1.9.0;
if you want to use a current (1.9.0) kernel you'll need a binutils
from a month or two ago; the sifive/freedom-u-sdk repo has submodules
for linux and binutils (via gnu-toolchain) which I know work together.

>> > The question is if LLVM is enough ready. GHC is quite a beast and
>> > although it supports cross-compilation it is always better to use
>> > native-compilation to be able to run testsuite. Hence question of how
>> > emulators are fast or how the fastest hardware available is fast...
>>
>> Well, LLVM doesn't need to be ready at the moment since first step may
>> be to get GHC unregisterised build working.
>
>
> I was able to prepare an unregisterised stage1 cross-compiler inside of
> sbate's Docker image without much trouble on Friday. The "hello world"
> executable that it produced ran successfully on the emulator.

If you want to test "native compilation" scenarios without fussing
with kernels, (and the current system-level emulation is missing
enough features that it's painful to use even when it is working),
qemu-user works very well. I have a docker image
sorear/fedora-riscv-wip which produces an emulated user-level
environment, can install various tools from our local dnf repository,
can do a 3-stage gcc bootstrap in 8 hours on a laptop.

(It breaks from time to time due to incompatible changes in the dnf
repository. Let me know if that happens.)

-s