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割ある。
それと、計算式処理の部分をもう一回整理したい。

出口が見えてきた

今週は辛い作業になるだろうと思っていたが、意外と簡単に出口が見えてきた。
10年前の俺が残した文書がずいぶん役立った。
ありがとう。10年前の俺。確かに受け取ったぞ。

今日は早めに帰って来たので、先週までやっていたラインアセンブラのしらみつぶしテスト用コードの改造作業を始めた。
今日はそのコードを探すだけ。
今年の3月にUbuntuに乗り換えたので、古い機械のHDD内をあさらなければならない。
もうずいぶん前に書いたものなので、どこにしまったか忘れてしまった。数年前、異常に忙しい暑い夏にPCが壊れ、応急的に安いPCを買ってきて作業を続行し、その冬に新型機を買い、暑さで壊れたPCと応急PCから、少しずつデータをコピーしていた(なかなかまとまった時間がとれなかった)。
そのせいで、非常にごちゃごちゃしたディレクトリ構成になっていた。
また、何で開発していたかもよく覚えていない。Virtualマシン上のLinuxでの開発だったか、Cygwin上での開発だったか、Borland C++ Builderを使っていたか、Eclipseを使っていたか。Eclipseは、Windows上で動くものが3本(一本は特定のマイコン専用)入っていて、Linux上で動くものが1本あった。
findで探そうにも、ファイル名を忘れているので手がでない。

しばらく探して、やっと見つかった。
その他、懐かしいものも色々見つかった。
タイムスタンプを確認すると2010年12月にいじったのが最後だ。つまり、その時点でdisasmの作業は終わっていた。
約2年放置していた事になる。
最後にいじってから、しばらく東京をはなれており、その後年度末のドタバタが始まり、3.11があった。
妙に忙しかったり、暇でも電気がなかったりして、いつの間にやらほったらかしモードになった。
今年になってだいぶ落ち着いたが、3月にUbuntuへの乗り換えをしてしまったため、使い方の習得や開発環境の再構築、VAIO C1-VRX/K用のFrameBufferドライバ改造など、余計な事をたくさんやっていた。

この数年だけでも色々なことがあったものだ。
夜に一時間だけで書いているコードなので、あまり頭を使わないでもいい書き方になっている。
しかしながら、重要な部分へのコメントは書いてあり、その当時の努力を感じる。
未だに、昼にばっちり働いて、夜に別の作業をするには勢いをつけないといけない。帰宅途中に「帰ったら、やるぞ！」みたいに気分を盛り上げておいて、帰り着いたらすぐに作業を始める。
その当時もそのように踏ん張っていたのだろう。

どんなに困難な作業でも、諦めずに続ければ、いつかは出口に到達できる。
自宅での作業も出口が見えてきた。
明日は発掘されたソースの改造方法を検討しよう。

雲見で潜ってエネルギー充填

雲見へ行ってきた。最高の海況で楽しめた。

天気は最高。水温20℃(俺のダイコンでは19℃)。透明度20m以上。
ロクハンなので、寒くない。水温的には、5mmでもイケたかも。
わずかに流れがあるが、流れる方向へのダイビング。
ドリフトダイビングになるほどでは無かったが、結構な距離を移動してもほとんど疲れない。
波、うねりはほ無し。

今回は、生姜のお茶を持っていって、みんなで飲んだ。
フィリピンで買ったフィリピン製、日本で買った日本製、日本で買った中国製の3種類を持っていったが、みんな日本製の生姜茶を選んでいた。「フィリピン製もピリリとして、おいしいよ。」と奨めてみたが、ダメだった。
自分はフィリピン製の生姜茶と中国製の生姜茶を飲んだ。
生姜茶をたくさん持っていったので、カメラは無し。

---

シマシマが無くなって、顔が黒くなっている超巨大イシダイを何匹も目撃した。
透明度の高さから広範囲が見渡せるためだろう。たぶん見えにくいだけで、ふだんからそれくらいはいるのだろう。
24アーチのテングダイも穴からでて外にいた。
キラキラ光るキビナゴの群れを下から見上げたり、ムレハタタテダイの群れがいたりと、群れモノも多かった。
ショップのボスの後ろをついて行っているとき、ボスのキックでイソギンチャクがひらりと舞い上がった。
そして、その下に小さなタコがいた。
タコはビックリして、すぐに穴に逃げ込んでいった。
エビがいるのでタコも多いと思うが、いつも隠れていてあまりみえない。

帰りに、大渋滞に巻き込まれ、19時ごろに厚木。
下道で移動していたので、厚木で夕食にした。厚木に住んでいたころ、しゃぶしゃぶ食べ放題だったお店が、ビフテキ、ハンバーグ、パスタを注文すると、サラダバー、カレーライス、パン、デザートが食べ放題になるお店になっていた。
そのお店で、ビフテキを食べた。
もちろん、サラダ、カレーライス、デザートも食べた。

---

明日からは、10年以上前に作った機械の中へ深く潜航して問題の調査をしなければならない。
しばらくは本当の海には潜れないだろう。
年末年始を心置きなく楽しむには、この仕事を綺麗に解決する必要がある。
デバッガ無しで作った装置だ。しかもOSにBugがあったため、メーカに少し修正してもらったものだ。
OSはその当時でも、もう少し良いものもあったが、そのメーカが出していたミドルウエア(FATドライバとTCP/IPプロトコルスタック)を利用したかったので、そのOSになった。
結局、装置開発時、OSやミドルウエアの不具合修正やチューニングをかなり行った(もちろんデバッガ無しで)。
その当時は今よりも若かったからできたが、今またそこへ潜るとなると、体力的にきついだろう。
わかっていても、またやらねばならない。

今日の海と食事が明日からのエネルギーとなってくれることを望む。

ラインアセンブラ３

結局、昨日の夜、食後にPUSHM, POPMも書いた。
過去に作ったMotorola-Sレコードにしたバイナリを逆アセンブラでアセンブリ言語化して、それをラインアセンブラに食わせた。
昨日の段階で、サイズが同じになることは確認していた。

今日になって、バイナリを逆アセンブラに食わせて、そこから出てくるコードをラインアセンブラに食わせて、それを最初に入力したバイナリと比較するテストプログラムを作成した。

色々な部分で間違いが見つかった。
対向試験で逆アセンブラにも間違いが見つかるかとも思ったが、間違いがみつかったのはラインアセンブラのみだった。夜1時間ずつ、2週間で書いたものだ。特にバイナリの合成なんて、昨日半日で書いたものだ。こんなもんだろう。
1～2時間で完全に一致するようになった。
テストに用いたデータはCコンパイラが吐いたバイナリなので、あまりトリッキーなコードではない。
多分まだまだBugがあるだろう。

洗濯物をしたり、なんだかんだで、今日はこれくらいしかできなかった。
明日は海へ潜りに行く予定。

ラインアセンブラ２

例のこれが、だいたいまとまってきた。
字句解析、構文解析、命令とオペランドのデコード、Emulated命令→Native命令変換までは、先週と今週の月～木までかけて帰宅後1時間ずつで実装した。
ダイビングに行ったり、飲み会に行ったりしていたので、あまり集中できず時間がかかった。

今日の朝、Emulated命令→Native命令の動作確認をした。
いくつか間違いが見つかった。
毎日１時間ずつだと、途中で考えが変わったり、また全体を見ないので、不整合を見落としやすい。
昼には単体の動作確認も終わり、いよいよバイナリコードの合成処理を実装し始めた。

似たような命令体系の部分でくくって、系列ごとに実装しながら、単体テストを行った。
(細かくは見ていない。来週以降、しらみつぶしにテストする予定)
テストと同時進行なので、夕方になっても実装作業が終わらなかった。
2命令(POPM, PUSHM)の実装を残して、疲れて来たので作業終了。
明日には、実装が終わるだろう。

来週からは、アセンブラ部分の結合テスト。
事前に作ってある逆アセンブラと組み合わせて、テストをする予定。
逆アセンブラ作成時に、しらみつぶしにテストするコードを用意していた。
それを使えば、テストプログラムの用意も楽だろう。

この手のコードはテストプログラムがとても大切だ。
ソースコードも重要だが、同じくらいテストプログラムも重要である。

ラインアセンブラ

既に2年前になる。

友人にたのまれて、某16bitマイコンのラインアセンブラ、逆アセンブラ付きモニタを作っている。
一回は一応動いた(その後に色々不具合が発見されている)のだが、ラインアセンブラのコードが気に入らず、作り直している。

逆アセンブラやラインアセンブラは、単純だが量がある。
特にアセンブラでどこまで受け付けるかの見極めが難しい。

例えば、リテラル値を数式で入れられるようにした。ペリフェラルレジスタの操作等でベースアドレス＋オフセットのように入力できて良いなと思ってのことだ。
数式の処理を実装するときに、C言語の演算子を使うことにした。
括弧で計算順序の調整もできる。10進数、16進数、2進数に加えて、C言語のように8進数も使える。
そして、止めときゃいいのに、三項演算子にまで手を出した。
そんなものリテラル値計算のどこに役立つんだよとも思いながらも、どうせ実装するんなら、全部みたいなノリでうっかりやってしまった。
三項演算子を含め、数式処理は正常に動作しているが、無駄にコードがでかく可読性も悪い。
そんな部分が随所にある。

時間のある時に、何日間かまとめてやればすぐに終わる作業だ。
しかし、毎日30分から1時間の作業の繰り返しでは、前日の作業は忘れてしまう。
毎日作業ができれば良いが、なかなかそうもいかない。一週間や一ヶ月開いてしまうこともよくある。
このような状況では、問題を切り分け、局所化して、小さな作業単位の組み合わせにせざるおえない。
部分的に「もう少し作り込んでも良いよな。」と思ったらヤバい。全体が見えていないのに、その部分だけを掘り下げてしまうと、完成後に全体を見るとアンバランスな感じになる。

それで結局作り直し。

今日はまた全体の設計を検討した。
メモ書きをたくさん書いた。メモ書きにしておけば、通勤電車の中でも検討できる。
明日も多分検討の続き。週の中頃以降から、まとめる作業に入る。
シンプルで、改造しやすい実装にしようと思っている。