Orz日記 by Akio Morita

_ [買いもの]Multilaneケーブル関係

ブラケット(ASP-7084-2L)とケーブル(iSAS-7384/0.5m)を クォーレストに発注

でも、 これってサイバネテックが 扱ってるSASADP-7084-2LとMiniSAS7384-05と同じものだと思うが大分安い...

_ [SAD]CaMonitorバックエンドのオーバーホール

• ポインタ型のchid/evidをintptr_tへキャストしてdoubleへ放り込む実装をid登録テーブルとそのハンドルに置き換え
• PutCBで呼び出すEPICS\$PutCB[]をFortranで再実装
• ValueCBでのdbr_*_t型のvalue取り出し部を再実装
  • マクロによるコード生成に移行
  • 型変換をFortran側へ移譲(void *渡し・call C_F_POINTER)

現状、CaMonitorのValueCB経由の読み出しは、フル実装になったはず

残っているのは、

• EPICS\$CaPut, EPICS\$CaPutCBの再実装
  • 現状、DBF_STRINGと DBF_DOUBLEしか使えない
• src/tfefun2.f側の実装
  • CaOpen2にて、chidのリソースリーク
  • CaRead2にて、issueパートとretireパート間でwriteback bufferポインタをintptr_tキャストしてdoubleに放り込んで渡している
    • 生成したList要素をスタックに積み上げているので、vstk側の隙間にktastk経由(integer64 == intptr_t)で詰め込めるはず
    • さもなくば、Native型で追加のstack frameを確保して積み込むべし
• evidテーブルリソースリーク
  • EPICS\$CaClearEventを行わず、EPICS\$CaClearChannelされるとchidテーブルは開放されるが、evidテーブルが開放されない
  • ca_clear_channelのマニュアルを読む限り、chidに紐付けされたevidは開放されるっぽぃ
    • 従って、今回導入したevidテーブルエントリー(8byte)のリーク
  • EPICS CA APIに、ca_evid_to_chidという関数が有るので、evidテーブルをスキャンして、chidとヒットをとることは出来る
    • evid → chid → chid-slot-numberは定数時間でたどれるが、逆にたどるテーブルは用意されていないので、真面目にやると線形スキャン
    • 最善のケースでは、evidが開放済みなので検索が無駄になる。特に、登録数が多いときにもったいない
    • chidに対して、evidの割り当ての有無が分かると効率化出来る
      • 線形スキャン中に全数回収した時点で終了出来る
      • CaMonitorクラスの実装では、基本的にchid辺りのevidはたかだか1個なので、ポインタ型のアライメントによる空き領域に埋め込めるが…
      • 呼び出し元を限定出来ないので、カウンタを設けるべきであろう
      • chid_tableの実装を構造体にするか2テーブルにするかは選択の余地あり
        • アライメントの厳しいマシンでは、構造体にするとパディングロスが増える
        • 2テーブルだとreallocationのコードでのエラーチェックで面倒が増える

_ [SAD]SAD stack backend

ごそごそ整理を実施

• *stk array equivalenceを配列ポインタへ置き換え
• *stk配列ポインタの有効化範囲は、スタックの有効領域に限定
  • range checkerを使えば、スタック境界越えを検知出来る
• *stk配列ポインタの割当て部とSAD stackの初期化部を分離
  • 途中からのスタック拡張を想定
  • mmap/mprotectでガード付きstack pageの割当てとSEGVハンドラによる実装を想定
  • mmap + カナリアページ/mprotectなハードフォールトでevalエンジン側でカナリアチェック(signalを使わない)実装もありか？
• 現行は後方互換な設定を採用している
  • *tastkとrlistのアドレス空間を整合
  • *tastkとvstkのイメージ距離をivstkoffsetに格納

次は、rlist回りの配列ポインタ化か？

• とりあえず、実行形式・拡張モジュールの更新が一段落するまで後方互換を維持
  • 現行のcommon変数rlistをrlist0へリネームして残す
  • 配列ポインタのアドレスイメージは、現行のrlist互換を維持する
  • src/pfalloc.fの inimemをオーバーホール
    • rlist配列ポインタの初期化
      • 第一段階 - 後方互換のため割当て済みrlist0から初期化する
      • 第二段階 - rlist0を排除して、初期ブロックをmallocで割り当てる(但し、rlistポインタのインデックスは調整する)
    • pfallocのルートノードの初期化

ivstkoffsetが現れるコード

• stringbuf系(src/tfprinta.fなど)
  • stringbufをSAD stackに割り付けるケースで、stringbufインデックスがon stackかどうかの判定に使用(2019/12/23追記 mst/ivstkoffsetではなく、vstk1のlbound/uboundで判定するように変更済み)
  • stringbufのアクセスは、rlist/tastk空間の互換性を仮定
    • on stack割付を無効化すれば、ivstkoffsetの影響はなくなる
  • stringbufのスコープが局所なら、allocatable配列を含む構造型で再実装すべきか？
    • Fortran的には変数スコープ離脱時に自動開放されることが期待出来る
    • C側からも任意に利用するならwrapper APIを設けるか、C側で実装してC_PTR渡し or ハンドラ渡しとすべき
    • allocatable配列の恩恵を受けるには変数スコープをFortran側に持たせる必要が有るため、C側でalloc/free出来ない(ポインタ・ハンドルを渡してwrapper API経由の操作は可能)

• tfsortl
  • tfreplace/tfoverride等からstack上に展開した要素列のソートをする際に、on stackな配列のrlistインデックスを渡している
  • rval_t配列のインデックス生成にivstkoffsetが必要
  • rlist/tastk空間の互換性が必要
  • 再実装するのであれば、stdlibの汎用のsortエンジンを使うか？
    • llvm/clang前提なら、sort_bでクロージャを渡せるが一般的ではない
    • qsort_r以外は、比較関数に文脈を直接渡せないのが難
    • overrideやreplace向けの同一要素の処理をどのように一般化するか？

• tfseval
  • stack上に展開した要素列をリストをして評価する際に、list containerの内部ベクトル互換なrlistに対するiad/iavインデックスで渡している
  • rval_t配列のインデックス生成にivstkoffsetが必要
  • rlist/tastk空間の互換性が必要
  • 比較的多数のstack展開演算子が相互依存している
    • Cポインタベースの実装を別途製作して、置き換えるべきか？