ポインタ型の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のコードでのエラーチェックで面倒が増える

[ツッコミを入れる]

2019-12-05

_ [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ポインタベースの実装を別途製作して、置き換えるべきか？

[ツッコミを入れる]

カテゴリー: Admin | Emacs | EPICS | Fortran | FreeBSD | GCC | hgsubversion | IPv6 | KEKB | LHC | Lisp | LLVM | MADX | Ryzen | SAD | samba | tDiary | unix | WWW | YaSAI | お仕事 | イベント | 出張 | 宴会 | 数学 | 艦これ | 買いもの | 追記 | 雑記