[Haskell-cafe] ANN: Topkata
Christoph Bauer
Topkata is a simple OpenGL Game written in Haskell. It's not very
advanced. Goal so far is to guide a ball trough an labyrinth to the
opposite corner. The web page shows an screenshot. It's only tested
under Linux.
http://home.arcor.de/chr_bauer/topkata.html
Feedback&Patches are welcome. BTW, I had a lot of support in #haskell!
Christoph Bauer
_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Neil Mitchell
> opposite corner. The web page shows an screenshot. It's only tested
> under Linux.
Looks cool! Could you upload it to hackage?
Once its on hackage, using cabal install, it should be possible to get
your game going with as little as:
cabal install topkata && topkata
That would be awsome for trying it out!
Thanks
Neil
Thomas Davie
> Hi All,
>
> Topkata is a simple OpenGL Game written in Haskell. It's not very
> advanced. Goal so far is to guide a ball trough an labyrinth to the
> opposite corner. The web page shows an screenshot. It's only tested
> under Linux.
>
> http://home.arcor.de/chr_bauer/topkata.html
>
> Feedback&Patches are welcome. BTW, I had a lot of support in #haskell!
Looks awesome, and I completely agree with Niel -- hackage it up!
In the mean time -- who knows enough to make ghc target ARM, and get
this to link against the iPhone libraries? This would be quite a coup
if it could be made to run there!
Bob
Christoph Bauer
> Looks cool! Could you upload it to hackage?
Thank you. Ok, I uploaded the current version. At the moment you have
to run topkata in the topkata-0.0 directory with
/dist/build/topkata/topkata, because it has to find its texture/sound
files. Furthermore I encounter problems (i.e. segmentation faults) on Gentoo
with the openal package. But openal-soft-1.4.272 works fine.
Christoph Bauer
Brent Yorgey
c-bauer-o...@t-online.de> wrote:
> Hello Neil,
>
> > Looks cool! Could you upload it to hackage?
>
> Thank you. Ok, I uploaded the current version. At the moment you have
> to run topkata in the topkata-0.0 directory with
> ./dist/build/topkata/topkata, because it has to find its texture/sound
> files.
There's a way to put something in the .cabal file about extra data files,
and have it install them in a certain location that you can then find
programmatically. I forget the details, but I think it's pretty easy to set
up. Maybe take a look through the Cabal documentation. Or maybe Duncan
will jump in and explain. =)
-Brent
Neil Mitchell
> > > Looks cool! Could you upload it to hackage?
> >
> > Thank you. Ok, I uploaded the current version. At the moment you have
> > to run topkata in the topkata-0.0 directory with
> > ./dist/build/topkata/topkata, because it has to find its texture/sound
> > files.
>
> There's a way to put something in the .cabal file about extra data files,
> and have it install them in a certain location that you can then find
> programmatically. I forget the details, but I think it's pretty easy to set
http://neilmitchell.blogspot.com/2008/02/adding-data-files-using-cabal.html
Thanks
Neil
Don Stewart
> On 14 Jun 2008, at 12:45, Christoph Bauer wrote:
>
> >Hi All,
> >
> >Topkata is a simple OpenGL Game written in Haskell. It's not very
> >advanced. Goal so far is to guide a ball trough an labyrinth to the
> >opposite corner. The web page shows an screenshot. It's only tested
> >under Linux.
> >
> >http://home.arcor.de/chr_bauer/topkata.html
> >
> >Feedback&Patches are welcome. BTW, I had a lot of support in #haskell!
>
> Looks awesome, and I completely agree with Niel -- hackage it up!
>
> In the mean time -- who knows enough to make ghc target ARM, and get
> this to link against the iPhone libraries? This would be quite a coup
> if it could be made to run there!
I'd be interested. We should start a wiki page for Haskell on the
iphone..
-- Don
Deborah Goldsmith
> tom.davie:
>> In the mean time -- who knows enough to make ghc target ARM, and get
>> this to link against the iPhone libraries? This would be quite a
>> coup
>> if it could be made to run there!
>
> I'd be interested. We should start a wiki page for Haskell on the
> iphone..
It's an interesting idea, but I think it would need to be a cross-
compiler. Does ghc support cross-compilation?
Deborah
Christoph Bauer
>> There's a way to put something in the .cabal file about extra data files,
>> and have it install them in a certain location that you can then find
>> programmatically. I forget the details, but I think it's pretty easy to set
>
> http://neilmitchell.blogspot.com/2008/02/adding-data-files-using-cabal.html
With this summary it was easy. I pushed an patch to
http://home.arcor.de/chr_bauer/topkata.
Christoph
Thomas Davie
On 15 Jun 2008, at 07:41, Deborah Goldsmith wrote:
> On Jun 14, 2008, at 1:06 PM, Don Stewart wrote:
>> tom.davie:
>>> In the mean time -- who knows enough to make ghc target ARM, and get
>>> this to link against the iPhone libraries? This would be quite a
>>> coup
>>> if it could be made to run there!
>>
>> I'd be interested. We should start a wiki page for Haskell on the
>> iphone..
>
> It's an interesting idea, but I think it would need to be a cross-
> compiler. Does ghc support cross-compilation?
The most obvious place to start I guess would be using -fvia-C and the
C cross compiler that apple supply. I'll certainly be looking into
this as soon as I get an iPhone (which unfortunately I need to wait
for 3G one in Belgium).
Bob
Ariel J. Birnbaum
> this to link against the iPhone libraries? This would be quite a coup
> if it could be made to run there!
Nintendo DS. Has anyone got any Haskell code to run on one of these?
PS: Maybe this discussion should be moved to a new "Haskell on ARM" thread?
--
Ariel J. Birnbaum
Xiao-Yong Jin
>> In the mean time -- who knows enough to make ghc target
>> ARM, and get this to link against the iPhone libraries?
>> This would be quite a coup if it could be made to run
>> there!
> For that matter, there's another ARM-based target in which
> I'm interested: Nintendo DS. Has anyone got any Haskell
> code to run on one of these? PS: Maybe this discussion
> should be moved to a new "Haskell on ARM" thread?
I would be interested to see ghc running on Nokia n8xx or
iRex iliad. Both of them are quite open linux based
systems.
--
c/* __o/*
<\ * (__
*/\ <
Don Stewart
> "Ariel J. Birnbaum" <val...@gmx.net> writes:
>
> >> In the mean time -- who knows enough to make ghc target
> >> ARM, and get this to link against the iPhone libraries?
> >> This would be quite a coup if it could be made to run
> >> there!
> > For that matter, there's another ARM-based target in which
> > I'm interested: Nintendo DS. Has anyone got any Haskell
> > code to run on one of these? PS: Maybe this discussion
> > should be moved to a new "Haskell on ARM" thread?
>
> I would be interested to see ghc running on Nokia n8xx or
> iRex iliad. Both of them are quite open linux based
> systems.
Jeremy Shaw had ghc targeting the nokia last year, iirc.
Perhaps he'll have more info.
-- Don
Jeremy Shaw
I have, on two occasions made an *unregisterised* of GHC for the ARM
(specifically the Maemo on Nokia 770). Mostly I just followed the
unregisterised porting directions in the GHC user manual.
I documented one attempt here:
http://hackage.haskell.org/trac/ghc/wiki/ArmLinuxGhc
Note: This procedure is for building a version of GHC that runs on ARM
and generates ARM code. So, it is not build a cross-compiler, just a
native ARM compiler.
The unregisterised build is not that useful because:
1. no FFI
2. uses trampolining for tail calls
3. no threads I think
4. some other stuff I have forgotten
So, the next step is to registerise the build. This is online a few
lines a code. Basically stuff like:
1. add ARM support to the evil mangler (basically, a few regexps to
strip prolog and epilogue stuff from the ASM)
2. #define which registers exist and what they should be used for
3. implement the tail call ASM
4. define some aspects of the C calling convention
5. (Optional), implement native assembly generation
This is not a lot of code. However, it is very low-level code.
I think that doing a registerised build is pretty easy, the *second*
time you do it. The big problem is that there is pretty much no
documentation on how to do it. (The porting guide does tell you, very
generally, what needs to be done).
Also, running GHC on an emulated ARM processor is slow. I think it
took GHC 6.4 8+ hours to build.
Now that many of the extra libs have been split out into the extra
libs package, that should help significantly with the build time.
If any does attempt to build for the ARM, please, please, please,
document what you do in the wiki. And, if you do, edit the wiki as you
go, you definitely won't be able to remember what you did after the
fact. (Or, at the very least, use some program to capture everything
you do so that you can refer to it later).
And, finally, I heard vague rumors a while ago that made me think that
GHC 6.10 might have a pure ANSI-C backend? Is there any truth to this?
That would make porting much easier if it meant you did not have to do
steps 1-4.
j.
ps. I would be happy to try to answer any questions if someone tries a
port. I would still like to run GHC on my 770, and I hope to own an
iPhone if they fix a few ommisions (bluetooth keyboard support, and
similar stuff).
At Tue, 17 Jun 2008 13:12:33 -0700,
Braden Shepherdson
> If any does attempt to build for the ARM, please, please, please,
> document what you do in the wiki. And, if you do, edit the wiki as you
> go, you definitely won't be able to remember what you did after the
> fact. (Or, at the very least, use some program to capture everything
> you do so that you can refer to it later).
>
> And, finally, I heard vague rumors a while ago that made me think that
> GHC 6.10 might have a pure ANSI-C backend? Is there any truth to this?
> That would make porting much easier if it meant you did not have to do
> steps 1-4.
>
> j.
>
> ps. I would be happy to try to answer any questions if someone tries a
> port. I would still like to run GHC on my 770, and I hope to own an
> iPhone if they fix a few ommisions (bluetooth keyboard support, and
> similar stuff).
>
I recently acquired the ARM-based Nokia N810 (and <3 it), powered by
Maemo. Running a uname -a on it:
Linux Nokia-N810-42-19 2.6.21-omap1 #2 Fri Nov 16 16:24:58 EET 2007
armv6l unknown
I would love a working GHC implementation on it, if for nothing else
than how awesome it would be. Whether that means using a C back-end or
native compilation doesn't matter to me so much.
I might be one to attempt this, as I know C and ARM-ish asm decently
well and have a powerful desktop to compile on. I have no familiarity
with GHC internals, though. Lastly, I won't have anything like the time
to attempt this seriously until mid-September or so.
Braden Shepherdson
shepheb
Ian Lynagh
>
> The unregisterised build is not that useful because:
>
> 1. no FFI
If libffi supports it then this should now work.
> 1. add ARM support to the evil mangler (basically, a few regexps to
> strip prolog and epilogue stuff from the ASM)
Note that the mangler is on the way out for 6.10:
http://www.haskell.org/pipermail/cvs-ghc/2008-June/042979.html
> 5. (Optional), implement native assembly generation
You'll need to do this instead.
Thanks
Ian
Jeremy Shaw
Braden Shepherdson wrote:
> I recently acquired the ARM-based Nokia N810 (and <3 it), powered by
> Maemo. Running a uname -a on it:
> I might be one to attempt this, as I know C and ARM-ish asm decently
> well and have a powerful desktop to compile on. I have no familiarity
> with GHC internals, though.
I think that is a fine set of qualifications. The porting process
requires low-level knowledge of C, asm, and the ARM more than GHC
internals. It's mostly stuff like #defining what the names of the ARM
registers are, and which ones are preserved across C function calls.
Also, if you are not starting until at least Sept, waiting for 6.10
might be a good choice, since it sounds like the backend will be
changing quite a bit. No point in doing it twice if there is no rush.
j.
ps. Perhaps we should have some sort of GHC on the ARM hackathon when
6.10 comes out. I think there are quite a few people who have tried or
who are interested in trying a port. Having more heads look at it
would probably make things go faster.
Jeremy Apthorp
Oops, forgot to Cc the list.
Next year I'll be working on a project for my undergraduate computing
course at UNSW that will involve getting GHC to target the Nintendo
DS. It'll require cross-compilation, because the DS isn't powerful
enough to actually run GHC (4M main ram and a 66MHz processor). It'll
also require that I significantly strip down the runtime system, as
the current RTS won't fit in 4M and leave any left over for the main
application.
I'll be documenting the whole process, but I won't be starting until
next year...
Jeremy
Jeremy Shaw
Jeremy Apthorp wrote:
> Next year I'll be working on a project for my undergraduate computing
> course at UNSW that will involve getting GHC to target the Nintendo
> DS. It'll require cross-compilation, because the DS isn't powerful
> enough to actually run GHC (4M main ram and a 66MHz processor).
Cool!
By cross-compilation, I assume you mean, a version of GHC which runs
on x86, but generates ARM assembly? Another option might be to use a
nintendo DS emulator which has been configured to support more RAM and
CPU power ?
A true cross-compiler would be nice though, because it will run much
faster. GHC does have some support for cross-compilation, but in the
current implementation, it is mostly (entirely?) there for
bootstrapping. I have no idea how the ghc backend rewrite for 6.10
will affect this.
Hope this helps,
j.
John Meacham
Haskell programs on on iPhone and a nokia n800 tablet compiled with it.
jhc is, of course, still pretty unstable. but new developers are always
welcome.
John
--
John Meacham - ⑆repetae.net⑆john⑈
Adrian Hey
Jeremy Apthorp wrote:
> Next year I'll be working on a project for my undergraduate computing
> course at UNSW that will involve getting GHC to target the Nintendo
> DS. It'll require cross-compilation, because the DS isn't powerful
> enough to actually run GHC (4M main ram and a 66MHz processor). It'll
> also require that I significantly strip down the runtime system, as
> the current RTS won't fit in 4M and leave any left over for the main
> application.
Maybe one of these would help (running Linux) ..
It'd be good too have a native code generator support for ARM (not via
C). Many years ago I tinkered with implementing a lazy FPL on ARM (on my
Acorn Risc PC). I never even started the compiler but got a basic single
threaded RTS and mark-sweep-compact garbage collector up and running
(written in ARM assembler).
It wasn't really useable for real programs though as I had to write my
function definitions as comments and actually implement the graph
reduction code by hand in assembler :-)
But I remember the ARM instruction set had some really useful features
that made things like checking for stack-heap collision cheap and if you
got the register allocation right (which is not hard on the ARM) you
could construct the overwhelming majority of heap records using a single
STMIA instruction. Almost seemed like it's instruction set was
designed for efficient FPL implementation :-)
Regards
--
Adrian Hey
Malcolm Wallace
Another semi-random note: nhc12 and nhc13 (precursors to nhc98) were
originally developed on an ARM with 2Mb of memory, way back in 1994-5.
Regards,
Malcolm
Jeremy Shaw
I have successfully run hugs on the Nokia N770.
j.
At Sat, 28 Jun 2008 22:39:00 +0100,
Jeremy Apthorp
> I have successfully run hugs on the Nokia N770.
hugs has also been successfully run on the Nintendo DS, as far as I'm
aware. However, my aim is to be able to write high-performance
applications (say, games) in haskell. An interpreter just isn't fast
enough.
Maybe I should try working on an inline C module too...
Jeremy
L.Guo
I just tried to port GHC 6.8.3 to my TI Davincci (c6446) board by
following the GHC Wiki Building/Porting page [1]. Both arm-compile
and cross-compile version have failed unfortunately.
So, I turn to try compile an local GHC on linux.
It takes me so many time.
I can not finish building it before off work.
[1] http://hackage.haskell.org/trac/ghc/wiki/Building/Porting#PortingGHCtoanewplatform
------------------
L.Guo
2008-07-02
-------------------------------------------------------------
From: Jeremy Shaw
At: 2008-06-28 02:57:38
Subject: Re: [Haskell-cafe] Re: Haskell on ARM (was Re: ANN: Topkata)
Don Stewart
It will be interesting to keep track of what we have tried,
what attempts failed and why.
-- Don
leaveye.guo:
Braden Shepherdson
> Could we start documenting this on the wiki ?
>
> It will be interesting to keep track of what we have tried,
> what attempts failed and why.
>
> -- Don
>
I've added some new sections to the top of the wiki page, above the
original attempts. It's now quite long, since it contains details of the
problems I encountered trying to build an unregisterised 6.9.20080614 as
a first experiment.
It ultimately failed because hc-file bootstrapping to a new platform has
been broken since 6.8. Only platforms with an existing GHC prior to 6.8
have 6.8 or later now, because of this. A bug[1] has been up since
mid-2007 detailing the problem. There's a self-proclaimed "quick hack"
diff[2], posted with the following comment:
> The diff I uploaded contains some comments inline. It's for ghc-6.8.2
> but also applies to the latest stable snapshot (ghc-6.8.2.20080401).
>
> As written earlier, it's possible to create a HC file bundle (with
> some additional created files) and to build a stage1 compiler with
> this. I'm a little bit uncertain how to proceed -- either go ahead
> using libcompat (which is a little bit ugly), or try to rebuild all
> the libraries immediately with that stage1 compiler (but without using
> utils/ghc-pkg, since it's not yet buildable), then build the remaining
> tools.
The bug is milestoned for 6.10.1, and the owner, Ian Lynagh (Igloo),
said on #haskell that 6.10.1 merely meant "soon".
So, assuming some GHC dev doesn't swoop down and fix this, what options
are left to the project in the short term?
An unregisterised build of an old 6.6 should work, that would get us a
working, though aging, GHC. Unfortunately a lot of the porting work to
move from that first unregisterised build to a registerised one (even
without native code-gen) wouldn't be transferable to a later 6.9 or
6.10, since 6.9 has moved from using the Evil Mangler to libffi.
As to running GHC on a real ARM device, several steps beyond the first
unregisterised build would have to be taken, regardless of GHC version:
1. Registerise it. Pre-6.9, this means porting parts of the Evil
Mangler, for which there is a guide. Post-6.9, this is much easier.
2. Native code-gen. Registerised or not, a GHC without native code
generation relies on a working gcc. That means a GHC for ARM without NCG
would only allow compilation of apps in the development environment,
though the binaries should work on the device.
3. Finally, even GHC with native code-gen seems to rely on ld and maybe
a few other binutils, but this is much, much lighter than installing all
of gcc.
So, moving forward I intend to run an unregisterised 6.6 build, just to
prove that it can be done. Where we go from there is up in the air. I'd
be inclined at that point to wait for 6.10 if #1346 really gets fixed.
Fully porting an old version seems like extra work that will hopefully
be obsoleted.
Comments here or on the wiki page are most welcome, I'll be documenting
the quirks and changes for the second attempt with 6.6 there too.
And if someone in the GHC know wants to work #1346, they would be my hero.
Braden Shepherdson
shepheb
[1] http://hackage.haskell.org/trac/ghc/ticket/1346
[2] http://hackage.haskell.org/trac/ghc/attachment/ticket/1346/ghc.diff
Braden Shepherdson
> | Linux Nokia-N810-42-19 2.6.21-omap1 #2 Fri Nov 16 16:24:58 EET 2007
> | armv6l unknown
> |
> | I would love a working GHC implementation on it, if for nothing else
> | than how awesome it would be. Whether that means using a C back-end or
> | native compilation doesn't matter to me so much.
> |
> | I might be one to attempt this, as I know C and ARM-ish asm decently
> | well and have a powerful desktop to compile on. I have no familiarity
> | with GHC internals, though. Lastly, I won't have anything like the time
> | to attempt this seriously until mid-September or so.
>
>
> Simon
Well, I've documented three attempts in detail on the ArmLinuxGhc Trac
page[1]. In short, it doesn't work.
6.8 and 6.9 fail, expectedly, since bootstrapping is known to be
broken[2]. 6.6 might be made to work, but it didn't work with moderate
effort and so it seems foolish to invest that sort of energy into an old
version when the back end is being overhauled.
As it appears that the task will be much easier after the back end
changes, this project is effectively on hold until the 6.10 release. In
particular, bootstrapping needs to work. There is a bug[2] about this
with milestone set to 6.10.1. Hopefully a quick-and-dirty unregisterised
port will be easy after that, with registerised and possibly even
native code-gen on the horizon.
One question that has come up is, what external tools does GHC need to
build binaries on a given platform? When going via-c, is a complete C
toolchain necessary? When doing native code-gen, are ld or ar required,
or other binutils? If we magically had a 6.9 that would generate ARM
binaries, what would it take to run binaries built in the dev
environment on the device? Would it take more to run GHC itself on the
device?
Braden Shepherdson
shepheb
[1] http://hackage.haskell.org/trac/ghc/wiki/ArmLinuxGhc
[2] http://hackage.haskell.org/trac/ghc/ticket/1346
Simon Marlow
> So, assuming some GHC dev doesn't swoop down and fix this, what options
> are left to the project in the short term?
>
> An unregisterised build of an old 6.6 should work, that would get us a
> working, though aging, GHC. Unfortunately a lot of the porting work to
> move from that first unregisterised build to a registerised one (even
> without native code-gen) wouldn't be transferable to a later 6.9 or
> 6.10, since 6.9 has moved from using the Evil Mangler to libffi.
Sorry for the delay in replying. I'm not sure if you're aware, but when
you have an unregisterised 6.6 working, you can use that to build an
unregisterised 6.8 and later versions. Building the unregisterised 6.6
would just be a stepping stone to the latest version, and only needs to be
done once.
This may be moot if we get bootstrapping working again, but until then I'd
guess going via 6.6 is the easiest route.
For the registerised port, you really need a native code generator (the
mangler is on death row, yay). At a rough guess, I'd say porting the NCG
would take a couple of weeks or so for someone unfamiliar with the code.
Hopefully we'll improve that when we refactor the NCG as part of the
backend overhaul.
Cheers,
Simon
Simon Marlow
> Simon Marlow wrote:
>
>> For the registerised port, you really need a native code generator
>> (the mangler is on death row, yay). At a rough guess, I'd say porting
>> the NCG would take a couple of weeks or so for someone unfamiliar with
>> the code. Hopefully we'll improve that when we refactor the NCG as
>> part of the backend overhaul.
>
> time ago
> and looked at the NCG but didn't do it for PA-RISC because it was going
> to take too
> much time to understand. I was leaning towards the approach of trying
> to translate
> the code generator for another processor into PA-RISC.
There's some old documentation, some of it is still relevant but probably
much of it is out of date now:
http://darcs.haskell.org/ghc/docs/comm/the-beast/ncg.html
the best doc is the code, I'm afraid (but it has lot of illuminating
comments and you can get a long way with cut-and-paste).
Dan Mead
arm
do you guys thing telling ghc to emit C and then compiling that for arm is a
better route than
getting direct compilation to work?
-dan
Braden Shepherdson
> has there been any movement on this topic? i'm also interested in
> haskell on arm
>
>
> do you guys thing telling ghc to emit C and then compiling that for arm
> is a better route than
> getting direct compilation to work?
>
If you look on the GHC-on-ARM page[1], you'll find my attempts to
bootstrap GHC 6.6 (the last version where cross-compiling GHC actually
worked) to ARM.
The only success I had was in using jhc (not GHC) to generate portable
C, which cross-compiled and ran fine (on my Nokia N810). GHC's C
wouldn't compile out of the box, and I'm not sure what libraries or
other hackery is required to make it do so.
Details of the failed cross-compilation and success with jhc are on the
wiki page[1].
I'd love to have this working, but I have no time at all this term.
Braden Shepherdson
shepheb
[1] http://hackage.haskell.org/trac/ghc/wiki/ArmLinuxGhc
>
> Haskel...@haskell.org <mailto:Haskel...@haskell.org>
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
>
> ------------------------------------------------------------------------
Conrad Meyer
> Dan Mead wrote:
> > has there been any movement on this topic? i'm also interested in
> > haskell on arm
> >
> >
> > do you guys thing telling ghc to emit C and then compiling that for arm
> > is a better route than
> > getting direct compilation to work?
>
> If you look on the GHC-on-ARM page[1], you'll find my attempts to
> bootstrap GHC 6.6 (the last version where cross-compiling GHC actually
> worked) to ARM.
>
> The only success I had was in using jhc (not GHC) to generate portable
> C, which cross-compiled and ran fine (on my Nokia N810). GHC's C
> wouldn't compile out of the box, and I'm not sure what libraries or
> other hackery is required to make it do so.
>
> Details of the failed cross-compilation and success with jhc are on the
> wiki page[1].
>
> I'd love to have this working, but I have no time at all this term.
>
>
> Braden Shepherdson
> shepheb
Have you considered trying to bootstrap ghc with jhc?
Regards,
--
Conrad Meyer <kon...@tylerc.org>
Braden Shepherdson
> On Wednesday 28 January 2009 08:15:44 am Braden Shepherdson wrote:
>> Dan Mead wrote:
>>> has there been any movement on this topic? i'm also interested in
>>> haskell on arm
>>>
>>>
>>> do you guys thing telling ghc to emit C and then compiling that for arm
>>> is a better route than
>>> getting direct compilation to work?
>> If you look on the GHC-on-ARM page[1], you'll find my attempts to
>> bootstrap GHC 6.6 (the last version where cross-compiling GHC actually
>> worked) to ARM.
>>
>> The only success I had was in using jhc (not GHC) to generate portable
>> C, which cross-compiled and ran fine (on my Nokia N810). GHC's C
>> wouldn't compile out of the box, and I'm not sure what libraries or
>> other hackery is required to make it do so.
>>
>> Details of the failed cross-compilation and success with jhc are on the
>> wiki page[1].
>>
>> I'd love to have this working, but I have no time at all this term.
>>
>>
>> Braden Shepherdson
>> shepheb
>
> Have you considered trying to bootstrap ghc with jhc?
>
> Regards,
Unfortunately this is not possible. The Haskell code in GHC relies on
some GHC-only extensions. jhc can't compile GHC because it doesn't have
those extensions. jhc can't even compile itself, since it too relies on
those extensions.
Braden Shepherdson
shepheb
Anatoly Yakovenko
some issues with llvm when this was discusses a couple of years ago.
has anyone checked if that's the case?