毎日更新してやろうかとと思ったけど、さすがに無理。
そんな毎日帰宅してから、ネタを作れるほど元気ないっす。

突然ですが、Cellのいいところは
メインメモリ⇔ローカルストア(LS)　を　DMA
ローカルストア⇔レジスタ　を　奇数パイプ
レジスタ⇔演算器　を　偶数パイプ
と、並列化することにより、メインメモリから演算器までの間において、
DSPばりに滞りなくデータを流せることにあります。(たぶん)

じゃあ弱点は？
というと、よく言われるのがLSが256KBしかない、あたりでしょう。
確かにこれは、プログラミングの制約としては、かなり大きい。
マルチコアと併せて、プログラマへの負担はかなり大きくなってしまう。

けどこの辺は根性というか気合というか、
アイディアでカバーできるとするじゃないですか。無理やり。


で、それを差し引いても厄介だなあ、と思うのが命令セット。

cell.scei.co.jp/index_j.html
を見ると分かりますが、
SPEの命令セットって、レジスタが128本になってる代わりに、
オペコードが削られて、命令の種類がかなり限定的になっている。
演算全般が得意であって欲しいのに、意外と苦手な処理がある。

例えば、32bit同士の乗算。
できません。
やるなら、mpyh,mpyh,mpyuで部分積を3つ作ってから、
a,aで足しこんで完成。
(上位16bit同士の乗算は32bitに収まらないので計算不要)
遅延は10clkくらい。

といっても、32bit同士の掛け算ってそんなにSPEではないだろうから、
これは許せる。


個人的にまずそうだと思ったのが、
vector shortだと8スロットあるのに、
8スロット同時に積和ができないこと。

偶数スロット同士で掛け算してvector intを足すことはできるのですが、
これだと1命令で4スロットしか動かない。
その代わり、32bit精度なんだけど、
画像処理でそんなに精度要らないんだよね。
演算精度は12bitあれば十分。
パネルドライバが最近ようやく10bitになってきたくらいだから、
それ以上あっても出力には現状殆ど関係なくて、無駄なわけだ。

もし、8スロット同時に動かせれば、色々な映像処理の
理論上限スループットが倍近くになるだけに残念です。


altivecだと、vmhaddshsとか、
そういう16bit型で8スロット積和ができる便利な命令があるのにね。
ただ、altivecは32本しかレジスタがないので、十分なunroll-loopができないから、
ストールしやすく結局本来の力は出せない気がするので、
SPEの命令を削ってレジスタを増やす戦略は、
トータルでは間違いではないのかもしれない。
(それに、SPEにしかない命令もあるし、そこは一概に比較できない)


となると気になるのが、
altivecのレジスタを128本に拡張したという XBOX 360 の PX か。
altivec 機能互換かつフラットに128本扱うためには、
32bit固定長は諦めなくちゃならないので、
一度に見えるのは32本な窓とかバンクで対応してるのかな。
それとも64bit長命令？うーん、それは避けたいな。

てか、そういう情報ってどこにあるんじゃー。
よくわからんので寝る。