I got my ARM (v5) ghc cross compiler built the other day by making sure I had only the latest LLVM and Haskell Platform host packages, tweaking settings and commenting out haskeline and terminfo in the top level ghc.mk . There's something broken about terminfo but life's too short to worry about since it's not needed. The ARM cross ghc seems to product viable executables for simple code. Now a sister product is a PowerPC (MPC854E) and the ABI is gnuspe. In my PATH are (only) clangs and llcs from http://llvm.org/releases/3.4.2/clang+llvm-3.4.2-x86_64-unknown-ubuntu12.04.x... and ghc from https://www.haskell.org/platform/download/2014.2.0.0/haskell-platform-2014.2... Because of the none vendor I didn't seem able to put in the target I configured like this. ./configure --target=powerpc-linux-gnuspe --with-gcc=powerpc-none-linux-gnuspe-gcc --with-nm=powerpc-none-linux-gnuspe-nm --with-ld=powerpc-none-linux-gnuspe-ld --with-ar=powerpc-none-linux-gnuspe-ar --with-ranlib=powerpc-none-linux-gnuspe-ranlib This fails as follows. It seems to have generated x86 opcodes including movq unless it's something to do with GNU assembly trying to make everything have the same apparent instruction set then again %rcx and %esi are mentioned. ====== cp libffi/build/inst/lib/libffi.a rts/dist/build/libCffi_thr_l.a "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H64m -O0 -package-name ghc-prim-0.3.1.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XHaskell2010 -O -fllvm -no-user-package-db -rtsopts -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -c libraries/ghc-prim/./GHC/Types.hs -o libraries/ghc-prim/dist-install/build/GHC/Types.o /tmp/ghc30000_0/ghc30000_5.s: Assembler messages: /tmp/ghc30000_0/ghc30000_5.s:8:0: Error: Unrecognized opcode: `movl' and so on with opcodes such as jbe, leal, jmpq and also "junk at end of line: `rcx),%esi'" ====== in libffi/build/powerpc-unknown-linux-gnuspe there's a sensible config.log with x86_64 in the build variables and powerpc in the host and target ones. How do I go about making this work ? Thanks, Jon
I'd use NCG instead of LLVM and still there is something fishy about your setup since this generated assembly looks like x86 to me. Cheers, Karel On 11/ 4/14 01:34 PM, Jon Schneider wrote:
libraries/ghc-prim/dist-install/build/GHC/Types.o /tmp/ghc30000_0/ghc30000_5.s: Assembler messages:
/tmp/ghc30000_0/ghc30000_5.s:8:0: Error: Unrecognized opcode: `movl' and so on with opcodes such as jbe, leal, jmpq and also "junk at end of line: `rcx),%esi'" ======
Definitely but given I've just switched from a successfulish looking ARM version to a PowerPC x86 popping out was the last thing I expected. Though it's not the first time I have attempted to cross-compile with (slightly older versions of) clang/LLVM and found it confused about its architectures. I have since knocked the -fllvm from SRC_HC_OPTS and GhcStage1HcOpts and that got me past the immediate hurdle producing a powerpc---ghc which which I could compile a helloworld.hs but the result hangs. So far I've only got as far as checking that yes the entry point, _start has PowerPC and not complete garbage code. I shall dig a bit deeper today equipped with a flimsy knowledge of both Haskell and PowerPC. Jon
I'd use NCG instead of LLVM and still there is something fishy about your setup since this generated assembly looks like x86 to me.
Cheers, Karel
On 11/ 4/14 01:34 PM, Jon Schneider wrote:
libraries/ghc-prim/dist-install/build/GHC/Types.o /tmp/ghc30000_0/ghc30000_5.s: Assembler messages:
/tmp/ghc30000_0/ghc30000_5.s:8:0: Error: Unrecognized opcode: `movl' and so on with opcodes such as jbe, leal, jmpq and also "junk at end of line: `rcx),%esi'" ======
Considering that cross-compilation is a little-bit on bleeding edge still I would recommend to use common 32bit PowerPC host first to build and *test* GHC to know there is no outstanding issue. Then, when you know PPC NCG is in a good shape you can continue with cross-compilation attempts... Karel On 11/ 6/14 10:26 AM, Jon Schneider wrote:
Definitely but given I've just switched from a successfulish looking ARM version to a PowerPC x86 popping out was the last thing I expected.
Though it's not the first time I have attempted to cross-compile with (slightly older versions of) clang/LLVM and found it confused about its architectures.
I have since knocked the -fllvm from SRC_HC_OPTS and GhcStage1HcOpts and that got me past the immediate hurdle producing a powerpc---ghc which which I could compile a helloworld.hs but the result hangs. So far I've only got as far as checking that yes the entry point, _start has PowerPC and not complete garbage code. I shall dig a bit deeper today equipped with a flimsy knowledge of both Haskell and PowerPC.
Jon
I'd use NCG instead of LLVM and still there is something fishy about your setup since this generated assembly looks like x86 to me.
Cheers, Karel
On 11/ 4/14 01:34 PM, Jon Schneider wrote:
libraries/ghc-prim/dist-install/build/GHC/Types.o /tmp/ghc30000_0/ghc30000_5.s: Assembler messages:
/tmp/ghc30000_0/ghc30000_5.s:8:0: Error: Unrecognized opcode: `movl' and so on with opcodes such as jbe, leal, jmpq and also "junk at end of line: `rcx),%esi'" ======
I finally got some PowerPC output but found it hung (on the target). I suspected it might be that we're using an SPE rather than the more common EABI but quickly found that it is due to https://ghc.haskell.org/trac/ghc/ticket/7695, possibly to be fixed soon according to the clear status notes for 7.10.1 and in any case easily work roundable by providing a UTF-32.so . Further good news is that what we want to do is purely mathematical manipulating only bitmaps, already has an implementation with tests in another language and ought to lend itself well to Haskell according to my learned colleague. So we can now proceed with some gentle performance testing on both our product platforms. I assume that NGC is what you get by default. helloworld works with or without -fvia-C when it clearly uses power---gcc. Jon
participants (2)
-
Jon Schneider -
Karel Gardas