新千葉 ガーベージ・コレクション

FPGA マガジンやインターフェースで書けなかったこと等をちょぼちょぼ書いてます。@ryos36

FS01BUからSIMカードが外せなかった、、、

検索すると
FS01BUからSIMカードが外せなかったので、分解して取り出す – まつぼ x Web
がひかかった。ここまでわかれば分解しなくても外せそう。ということで、ノートを切って隙間に差し込むと nanosim のひっかかりがなくなり、ちゃんと外せました。分解しなくても大丈夫。

CPS のメモ

CPS で APPLY が出てくることろで、割り込みをチェックして、割り込みルーチンに飛ばす。そして、その中でレジスタの切り替えとコンテキストの切り替えをすれば、VM 上でうまくマルチタスクが出来そう。割り込み性能が落ちる。がそれはそれ、そもそも VM で CPU をシミュレーションしているからなのであって、最終的に VM じゃなくて FPGA 上で走るリアルなVM(なにいっているんだか）にすれば解決する、、、、きがするぞ。

vm と割り込み

VM をつくっているひとは割り込みについてどう実装しているのだろう？実際の CPU の動きは割り込みがあがると別のアドレスにジャンプしたりするわけだが、VM ではどう実装すればよいのだ？単純にはどっかのフラグを"毎回"見て必要があればジャンプすればよい。しかし、これでは効率が悪すぎるだろう。折角（おれおれVMを）スレッデッドにした意味がなくなるのではないか？
Qemu は確か、ブロックごとにわけて、ブロック処理毎に割り込みを見ていたと思う。
タスク切り替えやエクセプションも問題になりそう。

vivado で突然ダウンロードケーブル経由の作業が出来なくなる

なんかの拍子に Vivado で Platform Cable USB II 経由で作業が出来なくなった。SDK もだめ。最初の理由はわからない。単純にケーブルの抜き差しか電源の off/on で大丈夫だったのかもしれない。
落ち着いて対処すればよかったのだが、慌てていろんなことをしてしまった。決定的だったのが、Jungo の windriver の更新。MS 経由だから安全だろうと思って最新の 11.5 にしてしまった。これがだめだった。恐らく、Platform Cable USB II のドライバと整合性がなくなった。
今考えるとデバイスマネジャーで元に戻すだけでよかった気もする。

対処方法は、

  • デバイスマネージャーで Jungo の windriver を削除
  • /Windows/System32/drivers/windrvr6.sys を確認
  • 存在するなら削除
  • 再起動(念のため)
  • デバイスマネージャで windriver がないことと drivers の下に windrvr6.sys がないことを確認
  • cmd.exe を管理者権限で起動
  • Vivado の /Xilinx/Vivado/2015.4/data/xicom/cable_drivers/nt64 へ移動
  • wdreg でインストール
wdreg -inf windrvr6.inf install

これで直った。正規の方法ではないので試すなら自己責任ということで。

ついでに書くと、混乱した原因の一つは Atmel の環境とのバッティング。今考えると atmel をインストールしていたから 11.5 がインストールされてしまったんだろう。
ここでも混乱して DriverMax とかいう妙なものまでインストールしてしまった（今は削除した）。この DriverMax は atmel のドライバの名称を使って流布されていたりするので気を付けないといけない。

とにかく慌てちゃダメ。

とりあえず hvm が Zynq で動く

おれおれ VM (gforth の vmgen でつくった) と、おれおれ Lisp コンパイラ、Zynq へもっていっても動いた。Linux だから当たり前か。

zynq> chmod +x ./hvm
zynq> ./hvm
Usage:hvm <vmb file>
zynq> ls
codes  hvm
zynq> ./hvm codes/test-00
test-001.vmb  test-003.vmb  test-005.vmb  test-007.vmb  test-009.vmb
test-002.vmb  test-004.vmb  test-006.vmb  test-008.vmb
zynq> ./hvm codes/test-001.vmb
halt 0
zynq> ./hvm codes/test-008.vmb
halt 32
zynq> ./hvm codes/test-009.vmb
halt 73
zynq> [ 1095.216768] random: nonblocking pool is initialized

zynq> ls
codes  hvm
zynq> sync
zynq> ls codes
test-001.vmb  test-003.vmb  test-005.vmb  test-007.vmb  test-009.vmb
test-002.vmb  test-004.vmb  test-006.vmb  test-008.vmb
zynq> ls
codes  hvm

原理的には Linux なしでも動くはずだが、、、

コンパイラの勉強会に向けて

コンパイラの勉強会（じゃないかもしれないけど、本人はそう思っている）にむけて駄文を重ねる。

CPS

CPS は「Compiling with Continuations」という本に詳しい。Kindle の本もある。これが、1992 年の本。ML を使っている。なんで ML なんだ～と一瞬思うが、後になってい見ると Appel の (Apple じゃないよ)先見性がわかる。英語を読むのは大変なので、http://www.eidos.ic.i.u-tokyo.ac.jp/~tau/lecture/scheme_compiler/gen/resume/all.pdfを読むとよい。この通りにやると Scheme のコンパイラができる。Lisp のいいところは構文解析がほぼいらないことね。

実際に作ってみた感想は、

  • コンパイラを作ることはそう難しくない
  • 最後にマシンコードに落とすところ（とくにスピル）はめんどくさい
  • VM に落としてしまえスピルはごまかせる
  • 浮動小数点を扱おうと思うと
  • Lisp での開発でなくてもよい（きっと Java とか使った方が簡単）

SSA

google の論文検索でさがせる。古い論文は再度そのタイトルで google で探すと（ついでに filetype:pdf とかすると）みつかったりする。わざわざどっかの研究機関の有料サービスを使うまでもない。

年段的にはやはり 1990 年代の初め位の研究が多い。つまり、CPS や SSA は 20年以上前の技術。重要だけど、もっと新しい技術を取り入れた方がいいのではないかという気になる。この時点で 25年遅れの私。

行番号などの付加情報

実際に Scheme でつくったが、多くの人は（わたしもそうだったが）コンパイラを作ることだけに焦点を絞っているので、その後でそのコンパイラを使って開発するところまでイメージしていない。だから、デバッグ機能がごっそりぬける。これは結構いたい。あとで付け加えることが困難。最初からこの辺の寄稿を考えながら実装するのがベター。

A正規形：CPS は否定された？

https://users.soe.ucsc.edu/~cormac/papers/pldi93.pdf を読むと CPS は否定されているようにおもった。理解していない。A正規形のコンパイラを作る必要があると感じた。

K 正規形というのもあるらしい。
A正規形とかCPSとか - sumiiの日記

ここまで到達すると 20 年遅れまで挽回する予定。

OCaml と型推論

よくわからないのだが、勉強中。「プログラミング in OCaml ~関数型プログラミングの基礎からGUI構築まで」がよくできている。絶版ぽい。Kindle 版がある。他の本はダメなのがある。出版社の問題。技術評論社はなんだかんだいってよいということか？

OCaml 型推論ができる。浮動小数点を扱おうとすると必須の機能。ML の系譜らしい。Appel の最新コンパイラ構築技法もなぜか ML 。Appel はここまで見通してたんだろうね。

Lisp が最強とか思って（思考停止していた）たけど、型推論で新たな扉が開いた感じがする。勉強しようっと。コンパイラも作る。住井先生という人の資料等が刺激になる。


ここまで到達すると 10 年遅れまで挽回する予定。

u-boot で外部の elf を実行する

fatls で確認

zynq-uboot> fatls mmc 0:1
    40687   hello_world

fatload で使ってなさそうなアドレスへロード

zynq-uboot> fatload mmc 0:1 0x3000000 hello_world
reading hello_world
40687 bytes read in 21 ms (1.8 MiB/s)

bootelf で実行

zynq-uboot> bootelf 0x3000000
## Starting application at 0x0c100000 ...
Example expects ABI version 6
Actual U-Boot ABI version 6
Hello World
argc = 1
argv[0] = "0x3000000"
argv[1] = "<NULL>"
Hit any key to exit ...

## Application terminated, rc = 0x0

理由はわからないが go コマンドだと暴走する。簡単に u-boot を追ってみると r9 が壊れていた。どうも、r9 に何かを入れる前提があるようだ。おそらく elf の load で解決される何か。