Orz日記 by Akio Morita

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