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

bfd/Makefile.am | 9
bfd/archures.c | 5
bfd/bfd-in2.h | 20
bfd/coffcode.h | 7
bfd/config.bfd | 18
bfd/configure | 1
bfd/configure.in | 1
bfd/cpu-powerpc.c | 30
bfd/cpu-spu.c | 63
bfd/doc/bfd.info | 131
bfd/doc/bfd.info-1 | 5921 ++++++++++++——
bfd/doc/chew.c | 6
bfd/elf.c | 172
bfd/elf32-spu.c | 1015 +++
bfd/elf64-ppc.c | 5
bfd/elflink.c | 7
bfd/opncls.c | 15
bfd/reloc.c | 27
bfd/targets.c | 2
binutils/ar.c | 9
binutils/doc/objcopy.1 | 9
binutils/objcopy.c | 74
binutils/readelf.c | 7
config.sub | 23
gas/Makefile.am | 16
gas/as.c | 9
gas/config/obj-coff.c | 243
gas/config/tc-ppc.c | 33
gas/config/tc-spu.c | 1006 +++
gas/config/tc-spu.h | 107
gas/configure.tgt | 5
gas/doc/as.info-1 |11236 ++++++++++++++++++++++++++++++++—- gas/doc/c-hppa.texi | 45
gas/testsuite/gas/sh/sh64/err-dsp.s | 2
gprof/gprof.info | 2326 ——-
include/bfdlink.h | 6
include/dis-asm.h | 1
include/elf/common.h | 1
include/elf/spu.h | 87
include/libiberty.h | 3
include/opcode/ppc.h | 3
include/opcode/spu-insns.h | 412 +
include/opcode/spu.h | 128
ld/Makefile.am | 8
ld/configure.tgt | 7
ld/deffile.h | 6
ld/emulparams/elf32_spu.sh | 14
ld/emulparams/elf64_lv2.sh | 51
ld/emulparams/elf64ppc.sh | 6
ld/emultempl/elf32.em | 7
ld/ld.texinfo | 8
ld/ldgram.y | 5
ld/ldmain.c | 15
ld/lexsup.c | 15
ld/pe-dll.c | 83
ld/scripttempl/elf.sc | 1
ld/scripttempl/pe.sc | 18
ld/testsuite/ld-scripts/assert.s | 1
ld/testsuite/ld-scripts/data.s | 1
libiberty/argv.c | 148
libiberty/config.table | 1
opcodes/Makefile.am | 10
opcodes/configure | 1
opcodes/configure.in | 1
opcodes/disassemble.c | 6
opcodes/ppc-dis.c | 22
opcodes/ppc-opc.c | 40
opcodes/spu-dis.c | 258
opcodes/spu-opc.c | 47
69 files changed, 18130 insertions(+), 5896 deletions(-)

2 hours after

bfd/Makefile.am | 9
bfd/archures.c | 5
bfd/bfd-in2.h | 20
bfd/config.bfd | 18
bfd/configure.in | 1
bfd/cpu-powerpc.c | 30 +
bfd/cpu-spu.c | 63 ++
bfd/elf.c | 172 ++++++
bfd/elf32-spu.c | 1015 ++++++++++++++++++++++++++++++++++++ bfd/elf64-ppc.c | 5
bfd/opncls.c | 15
bfd/reloc.c | 27
bfd/targets.c | 2
binutils/doc/objcopy.1 | 9
binutils/objcopy.c | 74 ++
binutils/readelf.c | 7
gas/Makefile.am | 16
gas/config/tc-ppc.c | 23
gas/config/tc-spu.c | 1006 +++++++++++++++++++++++++++++++++++
gas/config/tc-spu.h | 107 +++
gas/configure.tgt | 5
gas/testsuite/gas/sh/sh64/err-dsp.s | 2
include/bfdlink.h | 6
include/dis-asm.h | 1
include/elf/common.h | 1
include/elf/spu.h | 87 +++
include/opcode/ppc.h | 3
include/opcode/spu-insns.h | 412 ++++++++++++++
include/opcode/spu.h | 128 ++++
ld/Makefile.am | 8
ld/configure.tgt | 8
ld/emulparams/elf32_spu.sh | 14
ld/emulparams/elf64_lv2.sh | 51 +
ld/emulparams/elf64ppc.sh | 6
ld/emultempl/elf32.em | 7
ld/ld.texinfo | 8
ld/ldgram.y | 5
ld/ldmain.c | 15
ld/lexsup.c | 15
ld/scripttempl/elf.sc | 1
ld/scripttempl/pe.sc | 18
opcodes/Makefile.am | 10
opcodes/configure | 1
opcodes/configure.in | 1
opcodes/disassemble.c | 6
opcodes/ppc-dis.c | 22
opcodes/ppc-opc.c | 40 +
opcodes/spu-dis.c | 258 +++++++++
opcodes/spu-opc.c | 47 +
49 files changed, 3782 insertions(+), 28 deletions(-)

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.

Playing with Mambo Cell simulator part I

Since I was curious about it and someone on #ffmpeg pointed out that the cpu simulator now is working on ppc (before was just x86+fedora only) I started hacking a bit to see what’s available and how to get it working w/out having fedora in the equation (and maybe produce a nice stage3 to play with it…).

So far I had to mess around a bit to collect all the needed stuff and to get a glimpse on how they should build and play together.

Looks like there were too many people working on it w/out much coordination since you may easly start from a shell script that helpfully tries to fetch and check the packages you should require, then it tries to issue some make over a quite complex unpacked tree, then the Makefile calls rpmbuild to use some provided spec files that in turn will patch the mentioned sources, call some shell script, that will call make and ….

Well I guess you may see already the point. Once I got everything working using this convoluted way I’ll try to get everything working the gentoo way (as in having an overlay with app-emulation/mambo and add the spu patches to our toolchain to get a cross environment like the others)

If someonelse is interested and/or started already playing with it, any help is warmly welcomed, I don’t have much time so everything could be quite slow.

new stuff, new?

lots of media coverage about Picasa, a photo management tool, wow! ehm … hardly interesting.

There is plenty of program with equivalent features AND opensource AND native like
http://www.digikam.org if you like the all in one stuff or gqview.sourceforge.net if you want something lighter…

Those programs were around since ages, improved with time and aren’t in use just because are the new kool thing either because ported by a company known to provide nice stuff using some quite curious tricks or because is written with the new language du jour.

And yes, f-spot is based on a perversion of java that makes it completely non interesting

libnms

Ok, it’s an year that I’m pushing for it, looks like that’s still needed and hopefully it will be ready within the next month!

What?

well a rtsp client library that is tiny and almost clean to be used on the other opensource multimedia project out there. (see http://streaming.polito.it/ )

Currently we are cleaning and polishing the interface and adding the framer/parser logic to provide a full codec packet and not random fragments from the rtp layer.

developments… sort of

mlt is eventually in, jahshaka sadly doesn’t build against qt4 and that prevented me from committing it.

avifile is eventually dead and so oggvorbis and avi useflag. If you are looking puzzled at this announcement well: avifile is superceded by xine and ffmpeg for sure. The oggvorbis useflag now is split to ogg and vorbis, allowing a more finer distinction.

I hope to get an updated mplayer snapshot soon as I did with the newer ffmpeg snapshot that is in ~ right now. If you know some package that doesn’t build against it, please notify me and the upstream developers. Coordination and awareness is good always =)

In other news the person nicked doom9 made a fool of himself on the mencoder user ml[1] and on his forum[2], disqualifying libavcodec mpeg4 encoder because he doesn’t like people asking for bug reports (Michael Niedermayer, a great developer, famous for being patient) or people pointing faults in his comparison methods (Richard Felker, hot blooded mplayer developer and nitpicker). I spent the time reading the complaints on his forum and the ml thread and I could say that anybody who doesn’t understand the difference between a codec and a post processing stage or that if a decoder is bit exact another means that their output is the very same, should not say much about being unprofessional…

Notes: I’m not an ffmpeg developer or mplayer developer but I had to deal with both upstream and they aren’t bad at all. I just hate unfair treatments.

[1] http://news.gmane.org/gmane.comp.video.mencoder.user
[2] http://forum.doom9.org/showthread.php?t=104320&page=1&pp=20