July 2006 – Luca Barbato

The almighty cflags

Today was forced to close the Nth bug filled by someone that didn’t know what he was doing with the cflags. That was a waste of time of about 10minutes for 3 developers that actually had a look at the bug, another item that got in the mailbox of many other developers and another line in the bugzilla db.

I have nothing against try to get some performance from some experimental gcc optimization, you are free to do whatever you want on your system, but PLEASE, before filling a bug about missing registers while building something on x86 or amd64, turn OFF all your experimental stuff and just use -O2 -march=${yourcpu} -fomit-frame-pointer -pipe.

Thanks for the understanding.

Cell Toolchain – part II – act I – running in the gcc-cell lair

since:
– gcc-cell is quite a different beast (patches here, newcode there, backports everywhere!)
– diffing against the nearest gcc already in portage lead to a small 22MB patch

I just decided to use the provided tarball and live with it, that means that you have now also gcc-cell available in portage. Something else is almost ready… but I think I could sleep a bit now ^^;

crossdev cell?

Cell Toolchain – part II – act I – running in the gcc-cell lair

since:
– gcc-cell is quite a different beast (patches here, newcode there, backports everywhere!)
– diffing against the nearest gcc already in portage lead to a small 22MB patch

I just decided to use the provided tarball and live with it, that means that you have now also gcc-cell available in portage. Something else is almost ready… but I think I could sleep a bit now ^^;

crossdev cell?

Cell Toolchain – part I – act II – binutils complete!

You can get it from the usual place, it took some time to make everything behave as expected, but in the end I’m quite happy about this result, I’m just puzzled about the bfd configuration for spe since it just accepts raw *-elf and not linux-gnu as target.

Feedback quite appreciated ^^

Cell Toolchain – part I – act I – binutils

Today/This night I started ripping some clean patches out of the Cell toolchain-3.2 sources.
As I said in the previous rant, the whole toolchain is provided as a singular huge and messy tarball, no patches provided…

The first target is binutils since should be simpler. You may find in my devspace the first raw diff (about 1.2MB) against binutils-2.16.1 and the, 2hours of work, clean diff against binutils-2.17.

probably there is something else to retouch (I removed an ugly #undef TARGET_CPU #define TARGET_CPU “cellppu” and I hadn’t check yet the configure to see what is missing there)

but overall isn’t bad:

Before

2 hours after

Playing with Mambo Cell simulator part II

New release from IBM!

New and improve Cell SDK!

The new mambo works and works quite fine! I have already provided an ebuild for it and probably in short time I’ll add some gentoo custom bits to make working with it less annoying. You may check my overlay for it, I couldn’t get tile play with the tk UI yet but maybe I could try harder and have the simulator gui a tad nicer.

On the other side, there is the rest of the SDK is a nightmare =/

I bitched already about improper software distribution and seems that somebody read it since now the proposed medium is even more awkward: alloycanwatlowcarbnosourceincluded DAMN ISO IMAGE!

The fantastic iso image:

nemesi mnt # mount -o loop /tmp/CellSDK11.iso /mnt/iso/
nemesi mnt # ls iso
README.txt autorun css images pdfs
ShelExec.exe autorun.inf html media software

ShelExec.exe!?!

nemesi mnt # file iso/ShelExec.exe
iso/ShelExec.exe: MS-DOS executable PE for MS Windows (GUI) Intel 80386 32-bit

I hope that’s a joke…

Bright side: the pdfs in the same named dir are quite nice and is quite good have all the documentation in one place.

Dark side: again this is a fedora only distribution and the sources from bsc.es are again a messy tarball.