30th June 2010

Our CRUX PPC 2.6 ports and pre-compiled for the IcedTea Java Development Kit (OpenJDK) and OpenOffice suite are now updated. They are available for ppc and ppc64.

icedtea6-1.8 (openjdk6b18) --> icedtea6-1.8-946a062e9027 (openjdk6b20)
openoffice-3.1.1 --> openoffice-3.2.1

Low end machines owners can update their own systems using these provided bin-ppc* packages saving precious time and computational costs.

have fun with CRUX PPC !
--
GNU/Linux on Power Architecture
CRUX PPC - http://cruxppc.org/

_________________
acrux _at_ linuxmail _dot_ org

that's some nice stuff, acrux.

on a tangent, i tried recently to get LLVM head + clang to build on efika ppc, and even though the build succeeded, the resulting binaries crash deterministically each time i try to compile. as the build took me more than a day, i don't really feel like tweaking build options and re-doing it. so if somebody could produce working LLVM + clang binaries for 603 ppc, that'd be really nice too.

Did you try just compiling LLVM 2.7 + clang? Usually a release version - while not as featureful sometimes - is obviously with some more guarantee of stability. HEAD on LLVM and clang especially is a kind of extreme bleeding edge not usually seen on most other projects (except, perhaps, gcc itself, where LLVM has a lot less churn :)

_________________
Matt Sealey

i didn't try the official release, as i did have at the time a tad older revision (~100 revisions difference) built and working ok on a G4 mac. i thought that since that older revision was fine on a ppc, and there were no "major" changes in the commit logs related to ppc support, nor there were known gcc caveats listed in the llvm faq for the gcc version on my efika, i had a good chance at success. in retrospect, i was fairly naive in my assumption :/

12th Sept 2010

Our CRUX PPC 2.6 ports and pre-compiled for the IcedTea Java Development Kit (OpenJDK) with Zero VM are now updated. They are available for ppc and ppc64.

icedtea6-1.8-946a062e9027 (openjdk6b20) --> icedtea6-1.9 (openjdk6b20)

Low end machines owners can update their own systems using these provided icedtea6-bin-ppc* packages saving precious time and computational costs.

have fun with CRUX PPC !


--
GNU/Linux on Power Architecture
CRUX PPC - http://cruxppc.org/

_________________
acrux _at_ linuxmail _dot_ org

LLVM (port from CRUX) compiles fine on both ppc and ppc64 with CRUX PPC 2.6.

update - 13/09/2010
i've just now committed a specific llvm-2.7 port for CRUX PPC. I'm going to compile an IcedTea6-1.9 package for Power Architecture 32bit with Shark VM instead of Zero VM.

_________________
acrux _at_ linuxmail _dot_ org

Shark VM on 32bit platform is enough stable and usable and it'd be 5%-20% faster than Zero VM.

_________________
acrux _at_ linuxmail _dot_ org

Thanks, acrux, much appreciated! I'll give it a run as soon as possible.

ps: on a wild tanget, I was checking recently what gcc 4.4.1's scalar code-gen can achieve on the EfikaMX in the context of vector math (nothing fancy - just a small matrix4x4 x matrix4x4 testcase). Turns out that in VFPv3 RunFast mode, A8@800MHz is ~50% slower than 603e's FPU@400MHz at the given task, with code generated by a slightly-older gcc (4.2.1). Or in other words, VFPv3 has poor fp IPC (yeah, big news here) and one'd really want to use NEON-vectorized code on the A8 in those cases when FP vector performance matters. /useless piece of info with a skew toward auto-vertorizers

@ blu
i've just now forwarded to you an email thus you can download some pre-compiled ppc32 packages (there is llvm-2.7 too).

_________________
acrux _at_ linuxmail _dot_ org

@blu:
I know VFP is not good but
did you check the assembly Code that gcc generated?

Performance of GCC may be better for PowerPC than for ARM... (only a guess - I never used PowerPC myself)

yes, i did. but actually what is more interesting is the demonstrated IPC (instructions-per-clock) in both cases:

603e: 0.378 flops/clock
VFPv3-lite: 0.122 flops/clock

both are quite close to their theoretical limits of 2 flops/5 clocks, and 1 flop/7 clocks, respectively. so both compilers did a good job there, for scalar code, anyway.
actually lately there's been the opposite trend - gcc gets to do worse on ppc with the later compiler iterations. for instance, gcc 4.2.x produces better code for that little matrix x matrix testcase, than 4.3.x (i've not tried 4.4+.x there).