x86勉強会

昨日、x86勉強会に行ってきました。

Javaで作るx86エミュレータ d_kami

x86エミュレータを作るためにどのようなJavaのコードを書いたか。
x86命令について丁寧に説明してくれていました。しかし、x86の符号化は大変難しいので、
あの説明だけできちんと理解できる人がいたのかは謎です。

x86とプロセスについて masami256

プロセスがx86上でどのように動いているかという話。これも濃かった……。大体分かったのだけれど、ちゃんと復習しないとこれは忘れてしまう。

実行トレーサで学ぶx86再入門

これは入門だったのだろうか……。すごく濃いです。OSのメモリ保護を書き換えて、アプリケーションに検出されない
トレースを行う話。Exploitなプロセスを解析する際に必要であるらしい。

今どきのx86開発環境 Shougo

私の発表です。内容については実際のスライドを見た方が早いと思うよ！　誰ですか？　Vim勉強会と勘違いしていた人は。ぼくはまじめにx86のはっぴょうをしました。

中国製のMIPSエミュレータがどうやってx86をエミュレートするのか　syuu1228

MIPSとx86のエミュレートの話。MIPS勉強会おいしいです。きれいなMIPSがだんだんよごれていくさまがよくえがかれていました。誰得なんだろう。ちなみにスライドが英語でした。

8088のエミュレーションについて hdk_2

伝説のプログラマーであるhdk_2の少年時代の話と、中学生の時に作った（らしい）8088エミュレータの話。これを中学生のときに作るだなんて恐ろしいです。私は中学生の時、RPGツクールだったなぁ。自分も端末エミュレータ頑張りたくなりました。

新しいx86トレーサの作り方 a4lg

x86トレーサを作るために、どのように設計したかという話。egggardenさんの発表と似ていましたが、すごく理論的な話でした。学会発表おいしいです。

オマケ：
hdk_2さんはkterm, vi使いでした。Vimは入っていませんでした。高度な開発を行うときはEmacsのようです。私はもうviや素のVimなんて使えません……。

昔からCPUの話が好きなので、x86は大好物なのですが、内容があまりに濃すぎておなかがいっぱいです。
これは復習が必要だ……。
発表資料が早く公開されないかなぁ。
ちなみに、私の資料も後日公開予定です。当日見れなかった人はもう少しお待ちください。

※　８月２８日追記：資料を公開しました。
今どきのx86開発環境

レビュー：Emacsテクニックバイブル

ついにEmacsテクニックバイブルが発売されました。
購入者の感想を見ると、おおむね好評のようです。
しかし残念なことに、購入者の詳細なレビューがまだありません。
そこで、私がレビューすることにしました。

はじめに

まず、現在のEmacs本には大きな問題点があります。※１
Emacsはデフォルトの状態ではひどく使いにくく、プラグインをインストールして拡張するのが当たり前となっているのに、普通の本にはプラグインのインストール方法やその特徴についてほとんど触れていないのです。これにはプラグインが流行り廃りが激しく、時が経つとすぐに時代遅れになったり、新しいプラグインが出てくるという理由もあるでしょう。確かに、時が経っても有用性を保っている「入門 GNU Emacs 第三版」のような本は必要です。しかし、世の中にあるのがそういう表面をなでただけの本ばかりでは、初心者がいざ本格的にEmacsを使おうとしたときに挫折することは目に見えています。Software Design紙で連載されている「Emacsのトラノマキ」が好評であるように、現在には現在なりのEmacsの使い方があるのです。私は以前からそう言う本が必要だと考えていて、「るびきちさんがそう言う本を書いてくれるといいな」と妄想していたんですが、最近になって「Emacsテクニックバイブル」を執筆中だということで、自分の妄想が現実になり、大変驚いています。

内容について

内容については、「今までのるびきちさんのブログに書いてあったことをまとめた」というのが適切です。
るびきちさんのブログをよくチェックしている人には、あまり目新しい情報がないかもしれません。しかし、「今までばらばらだった情報がまとまっている」ことに大きな価値があります。
特に秀逸なのは後半２章のanything.el特集です。anything.elに関する情報が適切にまとまっています。
私は現在Vimにおけるanything環境として、unite.vimを開発中です。Emacsテクニックバイブルの購入理由も、「もっとanything.elを勉強して、unite.vimの開発に役立てたい」ということだったのですが、期待以上の出来だったので満足しています。
難点なのは一部のプラグインを除き、一つ一つのプラグインの解説は１ページ～２ページ程度と少ないことです。これはページ数の関係でやむを得ないことだったのでしょう。私としては、多少値段が上がっても良いから、もっとページを割いて欲しかったのですが。特にskk（ddskk）の解説は少ないです。そこは続刊に期待しましょう。

おわりに

「Emacsテクニックバイブル」という本ですが、それぞれのVimユーザーにも勉強になります。私はぜひともVimユーザーに本書を購入してもらい、Vimの「カイゼン」に励んでもらいたいと考えています。この本に込められたテクニックの数々は、あのKanaさんの「Vimの流儀」並に有用であることでしょう。
るびきちさんによると、この本が好評ならEmacs Lispプログラミング本を出す予定があるようです。
これは期待ですね。みなさんもEmacsテクニックバイブルを購入して、るびきちさんの次回作を応援しましょう。

※１：現在のVim本にも同じ問題点があります。
Vim Hacksでその状況をある程度改善していますが。Vim Hacksが本になるときは、「Vimテクニックバイブル」になるかもしれません:-)

CygwinでcursesアプリケーションをコンパイルするときのTips

最近、vimshellのtexeをテストするためにCygwin環境を整えているんですが、Cygwinでcursesアプリケーションをコンパイルするときに少しはまったのでここにメモしておきます。

Cygwinにはlibtermcap.aは存在しません。-ltermcapすると失敗するので、-ltisと変更します。それでもエラーが出るときは、cursesライブラリをリンクしていない可能性があります。-lcursesをMakefileに付け加えましょう。

Cygwinのcurses.hは/usr/include/ncursesという変な場所にあります。「curses.hが見つからない」というエラーになるときは、gccの引数に-I/usr/include/ncursesを加えてみましょう。

これでようやくfdcloneとslをコンパイルできました。texeがこれらのアプリケーションを実行できるようにしないといけません。

vimshellの新機能 texeについて

以前のエントリ後、h1mesukeさんはConqueに乗り換えたようでした。

その後h1mesukeさんは、Conqueの設定記事を書いてくれたようです。
Conqueはまだまだマイナーなプラグインで、情報が少ないので大変に参考になります。

上記の記事のトラックバック代わりに、vimshellの新機能であるtexeについて解説をします。
texeとはConqueと同様に、Vimを端末エミュレータとして使うというコマンドです。
vimshellバッファ上で、

texe zsh

のようにして起動しますが、vimshellバッファが欲しくないときには:VimShellTerminal zshとしても起動することができます。

texeと似たvimshellのコマンドとして、iexeというものがあります。こちらは対話的にバッファを生成し通信するのですが、texeとは細かい動作が異なります。
iexeはneocomplcacheと連携して補完ができたり、ヒストリを参照して実行できたりと、Vimの機能をほぼフルに使うことができます。しかし、texeの場合はバッファに対するすべての入力が奪われてしまうので、neocomplcacheは使えません。補完は起動するソフトの機能に依存します。そのあたりはConqueも同じです。加えてtexeはエスケープシーケンスの処理が重いので、私はインタプリタを起動するときにはiexeを使うことをおすすめします。ただし、zshの右プロンプトはiexeでは動作しません。どうしても右プロンプトを使いたいなら、texeを使用する必要があります。
iexeの方が優れているというのに、わざわざtexeを作った理由は、フル機能の端末が必要なニーズは確実に存在するためです。例えば、gdbtuiというものがあります。これは端末上でグラフィカルにデバッグを行うことができるソフトです。こういうものはiexe上では実行ができません。VimではEmacsのようなGDBとの連携がしづらいのですが、gdbtuiのようなソフトを使えば模倣できると考えました。端末エミュレータの機能を実装すれば、muttやw3mといったメールやWebブラウズもVimだけで実行できるということもあります。端末エミュレータの実装はそれなりに大変ですが、端末機能を使うすべてのプログラムとVimが連携できることを考えれば、実装する価値はあります。

Conqueとの比較

texeの良いところ

・vimshellと連携できる
・Conqueの対応していないエスケープシーケンスに対応
・Windows対応
・+pythonが必要ない
・洗練されたハイライト
・プロセスの後始末
・キーマッピングを自由に設定が可能
Conqueの対応していないエスケープシーケンスとは、例えばタイトルやカーソル形状の変更のエスケープシーケンスや、Line Drawing Character setのエミュレーションです。Conqueのハイライト設定は、実はvimshellのものを流用しています。が、vimshellのハイライトはその後独自に進化したので、当然texeの方が優れています。Windowsに対応するには、Cygwinのインストールとfakecygptyが必要です。動作もかなり重く、zshの自動補完を使うにはかなり無理があります。zshを普通に使う分には問題がありません。

texeの悪いところ

・エスケープシーケンスの実装はまだ不完全
・Conqueより重い？

まだ開発したばかりなので、動作速度やエスケープシーケンスの対応については、なかなか厳しかったりします。ようやく一通りの機能を実装することはできたので、今後改善予定です。

設定について

texeはfiletypeをterm-コマンド名として設定するので、
autocmd term-*で設定します。例えばこのように：

autocmd MyAutoCmd FileType term-* call s:terminal_settings()
function! s:terminal_settings()
  inoremap <buffer><expr> <Plug>(vimshell_term_send_semicolon) vimshell#term_mappings#send_key(';')
  inoremap <buffer><expr> j<Space> vimshell#term_mappings#send_key('j')
  "inoremap <silent><buffer><expr> <Up> vimshell#term_mappings#send_keys("\<ESC>[A")
  
  " Sticky key.
  imap <buffer><expr> ;  <SID>texe_sticky_func()

  " Escape key.
  iunmap <buffer> <ESC><ESC>
  imap <buffer> <ESC>         <Plug>(vimshell_term_send_escape)
endfunction

vimshell#term_mappings#send_key()という関数は、起動しているプログラムに送るキーシーケンスを制御しています。複数のキーシーケンスを送る場合はvimshell#term_mappings#send_keys()を使います。
ヘルパ関数が用意されているので、キーマッピングも自由自在なのです。
設定さえしてやればスティッキーシフトに対応することもできます。この柔軟性は大きな魅力です。

おわりに

texeには、まだVT100レベルの端末機能しか実装されていませんが、いずれは$TERMがxterm-256colorになる予定です。今後に期待してください。

neocomplcache Ver.5.1開発中

また期間が空いてしまいました……。Vim Hacksもあるので、ブログを続けるのはなかなか難しいですね。
まぁ、こちらにはこちらの良さがあるので、ブログをやめることは多分やりません。
しかしこんな濃いブログを見てる人なんているのだろうか。

本題です。私はvimshellの開発やeskkの修正で忙しかったりするのですが、neocomplcacheのバージョンアップも密かに進めています。それがneocomplcache Ver.5.1です。
http://github.com/Shougo/neocomplcache/tree/master

見ための変化はあまりないですが、プラグインの仕様がかなり変化しています。

ファイル名補完


vimshellとの連携


オムニ補完


Vimオムニ補完


レジスタ補完


クイックマッチ


neocomplcacheでは、「あまりユーザーがプラグインを書いてくれない」ということが大きな障害となっていました。
neocomplcache Ver.5.1はプラグインが書き易くなっているので、今度こそプラグイン製作者が増えるのではないかと期待しています。あとはドキュメントさえあれば完璧です。このあたりはVim Hacksでフォローする予定です。

Re: :shell vs vimshell

前回より、だいぶブログの更新があいてしまいました。なかなか続けるというのは難しいですね。まぁ、それはいいとして本題です。

h1mesukeさんのvimshellの感想として、「:shell vs vimshell」
http://d.hatena.ne.jp/h1mesuke/20100615/p1というページが公開されていました。本来ならばコメントとしてそちらのページに書き込む予定でしたが、長くなりそうなので、ブログでコメントを述べておきたいと思います。

この辺りのことは、Linux上でかつ端末内でのみ vim を使う自分にはそもそも問題になりません。:shell で起ち上がるのは zsh であり、強力です。*1

vimshellはもともと、Windowsの貧弱なコマンドライン環境を何とかするために開発されました。その後、プラグインとの連携性や、インタプリタ実行などの機能が付加され、現在のような姿になります。Linux上で、しかも端末上で使用するなら、それらの利点はあまりないかもしれません。

>実行している間はVimが止まってしまいます。

あまり格好良くはありませんが、別タブで（；^ω^）

>コマンドの出力もバッファにとれない

あまり格好良くはありませんが、xsel とかマウスによるコピペで。

それで満足できるなら、vimshellを使う意味はあまりないでしょう。vimshellはVimから出たくない、Vim上ですべてのコマンド実行を解決させたい人のためのものですから。

vimshell を使ってみてまず出鼻を挫かれるのは、.zshrc で定義している alias やシェル関数が効かないこと。l みたいなものから始まって、その数はかなりの量にのぼるので、それらを vimshell 上でも使えるようにするには、と考えるとちょっと気が遠くなりました。

はい。シェルの移行コストというのは高くて、それが新しいシェルがなかなか生まれない原因ではないかと私は考えています。なぜvimshellはzshの構文が使えないのかというと、vimshellはzshやbash, shとの互換性よりも、Vim Scriptとの親和性を考えて設計しているためです。加えて、私自身がシェルスクリプトの難解な構文や落とし穴が好きでない、というせいもあります。ただ、パイプはいずれ使えるようにします。zshの高度なリダイレクションもいずれは実装します。

使えるようにできたところで、２つのシェルの設定を抱えることになり、管理が二重化することは明白で、これは許容できないところです。

確かに設定の二重化は避けられないです。ただ、「これを許容できない」とありますが、本当にそうでしょうか。例えば、zshやbash(readline)でviキーバインドを愛用している人がいますが、これはzshとVimの設定の二重化です。あまりにVimに慣れすぎると、外の世界でもVimの設定を使いたくなります。「zshにVimのビジュアルモードを実装した」人がいますが、これこそ典型例だと思います。zsh上でVimの設定を模倣するくらいなら、Vim上でzshの設定を模倣してもいいと思いますが、どうでしょうか。

物事を単純にしたいのならシェルは一元化すべきで、:shell から普段使っているシェルを呼び出すのがラク。DRY原則重要。

一元化することは大事だと思います。私は一元化したことによって、zshの代わりにvimshellが標準シェルとなってしまいましたが。「Vimの設定 >>越えられない壁 zshの設定 >> screenの設定」なので、すべてがVimに吸収されてしまうのも容易に想像にできます。

とすると、自分はそもそも vimshell の恩恵を受けにくいところにいる、ということかも知れません。というか、多分そう。もしくは vimmerレベルが低いか（；^ω^）

まぁ、その方が幸せなのかもしれません。vimshellをありがたがるということは、もうVim病にかかっているということですから……。

指摘のあったとおり、vimshellはまだ完全ではありません。いつかはほぼzshを置き換えられるようにと考えて開発をしていますが、道はかなり険しいです。もし機会がありましたらまたvimshellを試してもらえるとありがたいです。きっとその頃には欠点も解消しているでしょう。

追記：「mattnさんのコメント」

mattn 個人的にはtailが動かないとエディタ内のシェルってそれほど意味を成さないと思ってる。

そんなあなたも大丈夫。bg tail -f もしくはiexe tail -fが使えます。

第四回 カーネル／VM探検隊

参加・LTしてきたのでまとめを書いておきます。

会場に到着したのは12:20頃。割とはやめ。会場はなかなか広かった。

１．kozosさんの発表
組み込みOSを作ったよ！　という話。今度本が出るみたい。
ちょっと興味ある。

２．yojiroさんの発表
OpenBSDのYUREXドライバはどのように解析したのか、おまけとして
「かわいくない」温度センサの解析秘話つき。
この人の発表は面白すぎました。あまたの名言が飛び出す。
「ドライバの気持ちは分かってた」
３時間でデバイスドライバをハック、すごい！

３．kobaさんの発表
組み込みの人らしいです。クロスコンパイル環境をqemuでごにょごにょしてたという話。

４．honmaさんの発表
ついにYUREXの話キター！
今日のハイライト。貧乏揺すりを科学したYUREX。CMが放送されたこともあるらしい。
一生のうちに貧乏揺すりをする回数をまじめに計算＝＞10桁あれば大丈夫だろう。
検証する動画がシュール。お値段は￥12,600（これでも採算ギリギリ）でしたが、
時代を先取りしすぎて（売れなかったので）￥980に値下げ。まさかの92% OFF！
YUREXのサイトがある。まじめに解説しすぎてて吹く。
デバイスドライバはPython製。Windows 7専用ドライバもある。
秘密の在庫がまさかのワンコイン。即売会は争奪戦でした。
何が彼らを熱くさせたのか……。どうしてこうなった！

休憩を挟み、ここからLTになった。
５．go_vmさんの発表
Plan9で動くYUREXのドライバを書いた！という話。
各OSでYUREXのドライバを書くというのが前回のカーネル／VM探検隊後にはやったらしい。
3月終わりのHacathonにて実装。Plan9のUSBドライバはユーザー空間で動作する。
USBデバイスはファイルとして見える。おお、確かに動いている。
時間がないので続きはWebで。github上で公開しているらしい。

６．noztosさんの発表
NetBSDとYUREXの話。5秒に一回ポーリング。Twitterに投稿できるらしい。

７．syuu1228さんの発表
OpenBSDにsgi SMPを実装。Theoさん直々にマシンを買わされた。
共有メモリアーキテクチャでクラスタを構成できる、ごく普通のHPC。
いわゆる変形合体ロボ。プロセッサローカルな空間があり、ローカルなIOとリモートのIOがある。
OpenBSDが持っているのは全部で四台らしいので、「もう一台送られてくるかも？」と言っていた。
質問にて、「sgi SMPをどこに送ればいいんですか？」に吹く。

８．xylaoさんの発表
UNIX/32Vをエミュレータで動かす。マイクロコードを修正した話。
すごく……CPUです。いや私は大好物なんですけど。
VAXのマイクロコードを解説。あれ、これは何の勉強会だったっけ。

９．masami256さんの発表
デバイスドライバを作ろう！とInterface別冊で勉強していた。
「使い方を説明するので誰か実装して」に吹く。

１０．siritoriさんの発表
高校生の発表。H8SXマイコン上で動作するOSを作ろうという話。
スライドでまさかのハプニング。卒業研究らしい。
そこにH8SXマイコンがあったから。
OSはまだ書けてないようだ。逆質問を受け付けていた。

１１．oza_x86さんの発表
会場に来れなかったらしく、Skypeで参加。
Dynamick tikcsはお仕事があるときだけタイマー割り込み。
利点は消費電力の低減とゲストOS時にCPU使用率の低下。
社会人になるというイベントがあったので4月はあまり実装できず。26日からやる。
27日にパッチを投げる。実際にテストしてもらえることになり、ToDoが増えた。
FreeBSD 7.Xで試せるようになった。パッチとソースはgithub上にあるらしい。
今後はFreeBSD 8.1めがけてマージしたいとのこと。

１２．yumano・murahueさんの発表
韓国のハッキングコンテストに参加。ハッキングコンテストの話はそこそこに、韓国話。
韓国で見つけたらしい「Kimchi and IT」に吹く。
fizzbuzbizbuz
韓国にはIT女子が多い。彼女たちはみんなバイナリアン。韓国は楽園！
バイナリアンかっこいい。

１３．ucqさんの発表
バイナリエディタで始めるプログラミング入門。タイトルはネタ。
Twitterでつぶやいてたら採用されたらしい。
「とりあえず、実行ファイルをバイナリエディタONLYで書きます」
実行ファイルの形式は、PE, ELF, COM, Mach-O, a.out, ....
そうだ、Plan9でいこう！　吹いた。
Plan9はフォーマットがシンプル。
ライブコーディングでバイナリエディタを使うプログラミング。これは斬新だ。胸が熱くなるな。
ヘッダの後に実行位置を書く。「ハンドアセンブルは面倒なのでNASMで」ですよねー。
デモは失敗……。残骸のコードが残ってしまっていたらしい。

１４．shudoさんの発表
いまどきのBinary Hacks 後編
Binary Hacksは大好評だったらしい。
Web系バイナリアン。かっこいい。
NerrymoserをデコードするためにLinux用のflv2mp3を利用することに。音声デバイスの出力を横取り。
「Segmentation Faultはお友達」
libX11.soで落ちてる。
バイナリエディタで書き換えたら動いた→さすがにこれはまずい。
GDB使ってブレークポイントを設定。
ioctlを呼んでスタックポインタがずれる。
よくよく眺めるためにlibcを逆アセンブル。
独自のioctlを使っているらしい。
処理を追うと末尾でなぜかジャンプ。この処理が悪さをしているらしい。
実行後にスタックポインタを補正して解決。
「binutilsはお友達」
みんなご愛用のバイナリエディタ。shudoさんはEmacsのhexl-modeを使っていた。

１５．d_kamiさんの発表
Javaでx86エミュレータを作った話。
OS作ったのでいろいろ知っていたが、命令コードのデコード方法は知らなかった。
ブログで宣言、Twitterで自分を追い込む。
アセンブリ言語のコードを実行できるようにする。
知らない命令を少しずつ実装中。現状は手抜きでプロテクトできてません！

１６．takahashiさんの発表
KVMをWindowsに移植した話。エミュレーションの処理が遅いようだ。
もうちょっと詳しく聞きたかった……。

１７．自分の発表 Vim = VM
VimはVMであると主張するいたって真面目なプレゼンだったはずなのに、
どうしてこうなった！　いろいろキワモノあつかいされました。反省はしていない。
詳細は発表資料を見てください。本当ならvimshellのデモをするはずだったのですが、一番最初に若干トラブったのとうまく画面切り替えできなかったので時間切れとなりました。

質問：Plan9でvimshellは動きますか？
答え：誰かが対応してくれれば……。私はLinux/Windows環境しかないので検証できません。
Macに対しても同じスタンス。ちなみに、Plan9にもVimはあるらしい。

質問：Emacs上でVimを動かせばいいのでは？
答え：エミュレーションにはあまり期待していない。それよりも、Emacsの優れた機能をVimに移植したい。

１８，１９：
もっと話を聞きたかったのですが、発表が終わった後で忙しくて話を聞けず……。

ベストオブLT（自分の中で）：
１．shudoさん
２．yojiroさん
３．oza_x86さん
４．ucqさん
５．syuu1228さん
みんなネタが濃い……。

全体に関する感想：
BSDとPlan9が大人気過ぎて吹く。なければ自分で（ドライバを）書くというその姿勢は見習いたい。
BSD系は比較的日本人コミッタが多いよね。なぜだろう？
自分の好きなOSを改造できるっていいな。
Vim = VMはもっと煮詰めれば真面目な研究課題として成り立つような気がする。
Vimからデバイスをいじれれば面白いですよね。真剣に検討しておこう。

ちなみに、力尽きたので懇親会には参加できませんでした。
何か質問があれば直接メール or github Issue or Twitterなどで。