Nexus7とKindle FireHD

Nexsus7に安いやつがでるらしい。
でも、買わないのだ。バカにされて買うもんか！そう簡単には買わないぞ。
でも小型タブレットは買いたい。

本当はVAIO C1-VRX/Kのサイズのやつがいいんだけど、それはSUMSUNGなので領土問題もあり、たとえ9割引だったとしても買う気がしない(タダまたは10割引Overだったら考えるかも...)。

ということで、Kindle FireHDにしようかと思っている。
やはり安いし、小さい。さらに今使っているC1 VRX/Kよりは高性能だろう。

Type-Pがある時に買っていれば...
まあしかたがない。
次の小さいのを待つくらいなら、Kindle FireHDを買ってあそぼうかな。

ちなみに、Kernelのコンパイルは、40時間程度で終わった模様。

VAIO PCG-C1 VRX/K でKernel compile

VAIO PCG-C1 VRX/K(10年以上前のH/W)に、Lubuntu 11.10を入れて使っている。
今年の3月ごろ、デスクトップ機はUbuntu 11.10だった。Kernelのバージョンが同じだったので、デスクトップ機でKernelをコンパイルして、atyfb.koのみをC1 VRX/Kにコピーして使っていた。
デスクトップ機は、Core2 Quadなので、Kernelコンパイルも速い(と言っても、数時間かかった)。
デスクトップをUbuntu 12.04に変えてしまったので、その作戦は使えない(Kernelのクロスコンパイルも出来るようだが、パッケージから作ることは出来ないだろう)。
C1 VRX/KのLubuntuも同じように上げればいいのかも知れないが、セルフビルドできるようにしておいた方がいいだろう。
この「Ubuntu 11.04ではじめてのカーネルコンパイル＆インストール」を見ながら、VRX/K(10年以上前のH/W)でlinux kernelのコンパイルを始めた。
もちろん、atyfb_base.cへのパッチを当てて。

デスクトップ機で、数時間かかったものだ。
C1 VRX/Kでどれくらいかかるだろう。

自作数独自動解決プログラム等で速度を比べると、C1 VRX/Kは10倍遅い。
コードもデータも小さいのでCacheにヒットし続ける。主記憶やHDDといった遅い部品の足かせがなく、プロセッサの性能差がもろにでる。そのため、10倍という差になったのだろう。
コンパイルなら、さすがにそこまでの性能差はでないと思いたいが、逆アセンブラやラインアセンブラの開発をしていると、デスクトップでは、コンパイルは一瞬で終わるのに、C1 VRX/Kでは数秒～10数秒かかるという事実もある。
RAMが176MBしかないというのが、問題なのかもしれない。

数日かかると思って、ゆっくり待とう。

10年前のミドルウエア

一昨日、確認したところ、一応動作していた。
しかし、Priority inversionで、出力タイミングに遅延が見えた。
致命的と言えるほどの遅延ではないので、そのままにする。
おそらく、12年前の実装の時点でそうだったのだろう。その時も同じ理由で放置した。

本当にPriority Inversionが原因なのかを一応色々工夫しながら確認した。
間違いないだろう。

製品に使っている組み込みOSはITRON準拠のリアルタイムOSと言っているが、実際には割り込みの扱いがひどく(割り込みマスクレベルがある機械でも、割り込みハンドラに入る際に、マスクレベルを最高にするため、割り込みの優先度がほぼ無意味になる)、高優先度の割り込みのリアルタイム性が著しく低い。
その他のミドルウエアとセットで使用するために、そのOSが選択されたが、12年前にまともに動作させるためにかなりのbugを自分たちで修正することになった。
10年以上前のものなので、その頃は品質の悪いミドルウエアも多かった(良いものが無かったわけではない)。結果的に、開発期間が半年ほど延びてしまった。
お客さんを助けるための開発だったのに、迷惑もかけた。
非常に辛い開発だった。その頃に「無理はいけない」、「ミドルウエアを使った開発は、そのミドルウエアを自分で作れるぐらいの技術力が必要である」という考えを持つようになった。

あまりにも不具合が多かったので、ミドルウエアの事をほとんど信用していない。
Priority Inversion(優先度逆転)が原因なら、Priority Inheritance(優先度継承)で対処すればよいということは、ITRON使いなら誰でもわかるだろう。
12年前なぜそうしなかったのか？おそらくミドルウエアのその部分にもbugがあった(ある)のだろう。
これについても確認した。
ソースコードをみるとやはりbugが発見された。致命的な不具合(システムの停止等)ではないが、優先度が継承されない可能性がある。
使っても使わなくても、最悪値は変わらない。そのため、使ってもいいのだが、ソースコード上で優先度継承をしているように見えて、実際にはそうではないというネジれた状態になる。ならばむしろ、堂々とソースコード上で「Priority inheritanceしていません」と見える方がいいだろう。
多分、12年前にも同じ結論に至ったのだろう。すっかり忘れているが。

実際に問題のSemaphoreのPriority Inheritance をEnableにして実験してみたが、発生頻度はやや減るものの、最悪値はほとんど変化なし。
RTOSに手を入れるのは、リスクがある。
はっきりと原因が特定されているが、とにかく元々Bugの多いものだ。
12年前の製品なので、今回もまた,そのままにすることにした。
「何とかしてくれ」と言われたらやることにする。

最近ではどのミドルウエアも枯れてきており、安定している。
さらに、チューニングもされている。
その製品の後継リニューアル版を作るときには、最新のミドルウエアにするだけで、限界性能が2倍ぐらい良くなるだろう。
ついでに12年動作実績のあるH/Wがある。これで最新ミドルウエアを評価すれば、問題の切り分け(H/W,ミドルウエア,ソフト)もかなり楽になる。

危機脱出成功

仕事が何とかなった。
とは言っても、やっぱ一晩はみないと安心できない。

仕事場を出てくる前に、テストを仕込んでおいた。
明日の朝、動いていれば成功だ。

ラインアセンブラ４

しらみつぶしテストをした。
通常使わないような命令の組み合わせで、ミスが見つかった。
また、間違いではないものの、逆アセンブルした内容をアセンブルした時に、元のバイナリとは異なるバイナリになるものもあった。それらが大量に引っかかった。

このマイコンのアセンブリ言語は、かなり変である。
アセンブリ言語１つに対して、表現方法が異なるマシン語が複数ある。
元々逆アセンブラ用のしらみつぶしテストは、アセンブラ表記では同じでも、マシン語では異なるバイナリの変換もテストしていたので、それをそのままアセンブラに喰わせると、どれかが元とは違うバイナリになる(１つは正しい変換になる)。
それらがあまりにも多い(しらみつぶしなので、テストの量が元々多い)ので、かなり苦労した。

テストはすべて成功するようになった。
かなり大量のテストをしているのに、PCでは一瞬で終わる。
何ともあっけない。
成功するようになったものの、このテストはアセンブラの異常系のテストができない。
逆アセンブラが吐くコードは正常なものだからだ。そのため、エラーメッセージの内容もチェックできない。
(メッセージのチェックを自動化するのは現在の人類にはほぼ不可能だろう)
まぁ、変な使い方をしなければ正常に動作するので、使えなくはないのだが。

どんなソフトウエアでも、作業量割合で見ると、重要な部分は全体の1割～2割だ。
それが動いたとしても、作業が1～2割が終わったところであり、残作業がまだ8割ある。
それと、計算式処理の部分をもう一回整理したい。