Orz日記 by Akio Morita

_ [雑記]メモリ検証

新品交換されたメモリーですが... 頻度は1/3程度に減っていますがやっぱりエラー出ますorz

00002/00041な組合せ

00041/00002な組合せ

00041/00002な組合せで9650SE実装後

_ [雑記]9650SEへのFreeBSDインストール試験

FreeBSD/i386 6.2-RC1をベースに 9650SEのドライバー組み込んだ スペシャルCDを製作して、9650SEなシステムディスクへインストールしてみる

問題なく、インストール成功

ddでの読み出し速度は、生のST9160821ASと同じ40MB/sが出ています(RAID1)

さて、パーテションはどう切ろうかな?

でも、9650SE上でのDriver番号と エンクロージャCSE-M14Tでのスロット番号の 対応関係が逆順なのは何故だろう

_ [KEKB]今年もお疲れさまでした

今年は、いつもより少し早い Winter Shutdownに突入

_ [SAD]最近のバックポートについて

CVS MAIN trunkへまめにバックポートが行われてますが、 ほとんどは ISO C99対応、POSIX等の C libraryの呼び出し仕様を 満足するための修正です。なんか、Tru64の C compilerは ISO C99対応みたいですが、POSIX等の仕様が古いままで printfがらみの新しいフォーマット文字列が未サポートのようですが 主にデバック出力関連な上、消え行くプラットフォームなので 気にしないように...

ただ、EPICS library linkageの更新では、build framework側の デフォルトをEPICS base-3.14.9に切替えているので、 USE_KEKB_EPICS=YESを使っている場合は、sad.confの 最後を新しいsad.conf.sampleの物と入れ換えないと 上手く動作しません。

あと、一部の64bit環境でプラットフォーム依存の拡張機能を 使って SADを動かすためのhackを入れてありますが、 使用を推奨するものではないのでデフォルトはOFFに してあります。必要なかたは、src/sim/unix_memory_.cを 熟読の上で自己責任で御利用下さい。

_ [SAD]Class実装覚書

Instance functionの定義評価は、当該Instance functionの最初のシンボル解決まで遅延される

つまり、環境依存(Instance symbolの評価値依存など)な定義は、 Instance function symbolの最初のシンボル解決時のコンテキストで評価される。

さらに言えば、関数呼び出しでは無くシンボル解決時なので 初期化シーケンス中にデバック目的でシンボル解決を行なうと状態が変わってしまうので要注意。

代表例は、Packages/CaSad2c.nのCaMonitor実装など

Runtimeでの条件分岐を減らす意味では有効だが、 シンボル解決時の暗黙のコンテキスト依存を使った実装は、 シンボル評価順序依存が入りデバックしにくくなる。

Symbol rebindingによる Singleton実装の方が可読性は高いと思われる。 (内部動作的には、Class.nが同等のことを行なう訳で大きなパフォーマンスメリットがあるとは思えない)

_ [SAD]range check

rlist pointerのrange更新コードを追加したので、添字検査を有効にして試してみたが、色々あってまともに添字検査が出来ない罠

• ilist(i, addr)系の参照でiが走るループが引っかかる
  • 領域は割付済みだが、Fortran配列の添字的には境界外なのも事実
  • ローカルにpointer参照を割り付けるのがFortran的には正しい？
• シンボル・文字列処理回りで、長さ付きcharacter・characterの配列・C_INT8_T配列を同一視して受け取るAPIが引っかかる
  • 特に別の型に複製する部分が酷いことになる
  • interface宣言付きで、コンパイル時にtype dispatchする or C_LOC経由で明示的に memcpyに渡す
    • C_LOCを使う場合、target属性が必要(面倒くさいことに)
• 無効参照(addr = 0な参照)のdereferenceを渡しているケースがある
  • 例えば、non-real typeなSAD objectに付随するrval部の参照
  • 正しくハンドルするには、参照の差し替え or type dispatchして即値渡しなので、conditional branchが増える
    • 3項演算子が無いので、コードが太る
    • C++のように、右辺値・左辺値を区別したoverloadが出来ないので、参照側で透過的な扱いが出来ない
    • 参照の生ポインタを透過的に渡すのであれば、NULLテストでおしまいなのだが…

一応、typo等に伴う無効参照等のバグが何件かかかっているので、無駄ではないがすぐに修正出来ない部分のrange checkを無効化するコストが高いのが難