obfuscatism

2026年、Amazon Kindle Scribe を買う

Fri, 31 Jul 2026 22:45:00 +0900

先日Amazon Kindle Scribe (2026)を購入した。 Kindle Oasis を長く使っていたので、それ以来のKindle端末の購入である。

Kindle Scribe の特徴

Kindle Scribeの主なスペック

11 インチディスプレイ
フロントライト無し（今回は安いほうを選択し、調光ライトも無いモデル）
プレミアムペン付き
New Amazon Kindle Scribe フロントライト非搭載モデル | 11インチディスプレイ、16GBストレージ、ノート機能搭載、プレミアムペン付き、グラファイト
MoKo Kindle Scribe 11 2026 ケース第3世代 11インチ Scribe Colorsoft マグネット吸着式 Black

カバーは公式のものではなく、別メーカーのものを同時購入した。重量は少々あるが、マグネットでKindle本体とよくくっついているので安定度は高い。

Oasis比体感スピード

そして、ページめくりが速い。 Kindle Oasisと比べて2倍くらい速くなったような気がする。 2024年モデルから速かったらしい。

ニュース記事を読んでいると、プロセッサ（SoC）も強化されたそうだ。ページめくりが速いということは、購入済み書籍のブラウジングや、ダウンロード済み書籍の検索なども素早く行えるようになっているということ。速度が速いだけではあるが、書籍を読む上で速いと嬉しい周辺のUIがかなり快適になっている。

プレミアムペンでの書き心地

これもまた体感的な感想にはなるが、ペンでの書き心地がとても良い。ディスプレイとペンの間に適度なざらざら感がある。

ブログネタや思考の整理を、病院の通院中に読書ついでに実行してみたりしている。

最後に

ただし、端末がデカいといえばデカい。ほぼiPadくらいある。大きい分、文字サイズも大きくして書籍を読みやすい状態にするのが正しい使い方であろう。。。

x86_64→ARM64 バイナリトランスレータの設計と実装

Thu, 25 Jun 2026 23:00:00 +0900

Rosetta 2を参考にバイナリトランスレータを作成したので、学んだことをブログにまとめる。趣味の文書のため網羅性・正確性は保証しないが、アーキテクチャの雰囲気は伝わるはず

はじめに

Rosetta 2 (Wikipedia) は、macOS上で動作する互換レイヤのソフトウェアである（Wikipedia Rosetta (software) (English)）。 Apple Silicon搭載Macであれば、x86_64（Intel Mac）向け実行ファイルをそのまま動かせる仕組みである技術的にはバイナリトランスレーションとAOT(Ahead of Time)をベースとしている。実行時の動的変換、あるいはAOTによる事前変換により、異なるCPUアーキテクチャのプログラムを短い起動・実行時間で動かす工夫がされている。

Rosetta 2について調べ、macOS向けに実装したのがこちら。 https://github.com/suma/rustmute

モチベーション

Wikipediaやニュースによると、将来Rosetta 2はmacOSから削除されるらしい。また、バイナリトランスレーションは漢のロマン、ということで実際にClaude Codeで実際に作ってどんなものか体験してみたい。

趣旨は次の点になる

macOS上で実際に動くバイナリトランスレーションの実装を作る（手でコードを書かず、コーディングエージェントClaude Codeの使用可）
x86_64向けのコードのCLIである程度は動くようにする
作ること、理解することが目的なので、各種属性（製品としてのクオリティ、速さ、安全性など）は重視しない。が、最後に気を付ける点をあげても面白いかもしれない
本ブログ執筆にあたって、LLM及び生成物（markdown, source code）は利用してもよい

このブログエントリで言及しないこと、書かないこと：

Claude CodeやLLMのプロンプト、ハウツー
バイナリトランスレータの作り方、実装の仕方など（だけど仕組みの解説はする！）
ソースコードのスニペットなどは貼り付けない

このブログエントリはLLMの生成物が一部入るかもだが、基本的には人間によって執筆されている。

設計の開始

Claude Codeで愚直にアーキテクチャを聞いたところ、Rosetta 2 クローンの設計はすぐ出てきた。書籍『System Design Interview』にありそうな内容で、実装するだけなら丁度良い難易度である。

全体

x86-64バイナリとそれが利用するdylib(shared object) を含め、命令をすべてユーザー空間で実行する。要するに、Apple Silicon以外のx86_64命令で書かれた実行ファイルを翻訳して動かすソフトウェアである。

実行モード

JIT （実行時あるいは動的に命令を翻訳する = 逆アセンブルして解釈されて実行される）
AOT（事前あるいは実行前に命令を逆アセンブル・変換しておき、実行時は翻訳済みコードを実行する）

時間の都合により、今回はJITのみ実装した。

設計

ローダー / プロセスの起動
デコーダ + IR リフタ (Lifter)
バックエンド（コード生成）
ランタイム
システム互換層

以下Claude Code生成によるコンポーネントの構成を示す。

プロジェクトの構成

好みで実装言語にRustを選択。プログラム名は Rustmute (Rust + transmute)とした。

crate 構成（これもClaude Codeによる生成）

rustmute-core 共通型、GuestCpu 状態、ゲストメモリ抽象、エラー型
rustmute-loader Mach-O 解析、dyld エミュレーション（依存解決・再配置・束縛）
rustmute-ir Rustmute IR 定義、IR ビルダ、最適化パス
rustmute-decoder iced-x86 によるデコード、x86 → IR リフタ
rustmute-arm64 ARM64 エンコーダ（dynasm ベース）、共通ロワリング
rustmute-jit JIT エンジン、ブロックキャッシュ、ディスパッチャ
rustmute-aot AOT コンパイラ、翻訳済み Mach-O/オブジェクト出力（未実装）
rustmute-runtime syscall/Mach trap 変換、シグナル、TLS、guest↔host ブリッジ
rustmute-cli Rustmute run foo, Rustmute compile foo -o foo.arm64

各コンポーネントの依存

逆アセンブラ、アセンブラのcrateを依存に追加し利用している。

rustmute-decoder
- iced-x86 … iced-x86 is a blazing fast and correct x86/x64 disassembler, assembler and instruction decoder written in Rust
rustmute-arm64
- dynasm … A plugin for assembling code at runtime. Combined with the runtime crate dynasmrt it can be used to write JIT compilers easily.
- dynasmrt … A simple runtime for assembling code at runtime. Combined with the plugin crate dynasm it can be used to write JIT compilers easily.

実装

Claude Codeの生成物ではある。今回作成のバイナリトランスレータRustmuteがどんな機能を持っているか記す。

Loader

実行ファイル及び動的ライブラリであるMach-Oやdylibの読み込みを行う。ファイル内のセクション、CPUの命令、文字列やテーブルなどの情報を読み込む。

既存crateを使うか、自作（Claude Code任せ）か迷うところで判断があったが、自動的に自作となった。自作の利点としてMach-Oの読み込みの際の自由度があがったと認識している。

覚えておくと良いキーワードとして、VA(Virtual Address)といったものがある（WindowsだとPEフォーマットでRelative Virtual Addressが出たかも）。ファイル上のオフセットを、ロード後の仮想アドレスに変換する必要がある。

セキュリティに気を使うならば、これらのファイルヘッダーの数値（サイズ、カウント）の値が過剰なまでに巨大になっていないかチェックしたり、数値の演算でオーバーフローになってないかチェックしてもよさそうである。

Loader その2 (dyld)

macOSのdyld (動的リンカー) を使うことも設計上の選択であった。

x86_64用にdyldを実装する
dyldの代わりに専用のランタイムで処理する（Rosetta 2）

参考： Appleシリコン搭載MacのRosetta 2 - Apple サポート (日本)

それとは別で、libcなどの関数をホストのRustmute側でラップして呼び出す方式（shim方式）もあったが、今回はRosetta型のsyscall trapの方式を採用することにした。速度を求めるなら当然libc内部をエミュレートしない方がもちろん速いのだが、今回はそこそこエミュレーションさせたいので私の好みでこうなった。

macOSの仕組みな話（確信があまりない）。

dyld … dyld (Dynamic Linker, 動的リンカー) は動的ライブラリをロードする。コード署名などのチェックといった役割も担う。
dyld_shared_cache … Appleの主要フレームワークを事前リンクしたキャッシュ。起動の高速化、メモリ節約、シンボル解決の高速化が利点。ここでmacOSのシステムの解説をしているということはつまり、バイナリトランスレータからx86_64の起動時にmacOSにおけるモジュールロードあたりでOSの知識が必要になってくるわけである。

キーワード： dylib, mach-o, virtual address, dyld, dyld_shared_cache

Decoder その1

命令のデコード（逆アセンブル）をし、それを後続に渡す。昔は練習で逆アセンブラを作りかけたが、x86の逆アセンブラは命令が複雑で学習目的に向かないと思う。当初から逆アセンブラは iced-x86 crate を考えていたが、自動的にこちらが採用となった。

x86（x64も）は可変長の命令セットのCPUアーキテクチャである。つまり、1バイトで表現する命令もあれば、2バイト・3バイト…で表現できる命令もあるわけだ。これは表現したい命令列を短いバイト数で表現できることもあるが、CPUのハードウェアを作るときも、バイナリトランスレータで利用する逆アセンブラを実装するとき命令が固定長のものを作るよりも難しくなる。

さいわいにも、Rustには iced-x86が存在したので助かったのだが、正確性だけでなく実行速度も速いとは恐れ入る。

Decoder その2（Lifter）

後述するIRという構造（表現）へ、抽象度を上げるのでLift（LiftしているコンポーネントをLifter）と言う。 IRになった段階で、後続(AOT/JIT)のために一部の最適化も実行できるようになる。

この段階で、実行できる最適化で代表的なものは以下のものがある。

遅延フラグ除去
レジスタの不要なコード除去(DCE, Dead code elimination)
定数畳み込み

ランタイム・JITエンジン及びsyscall

実質ここがプログラムの起点（main）であり、図のように実行ファイルを処理するentrypointとなるプログラムである。

syscallの実装は、Rustで書かれたlibcを呼び出したりしている。

Guest ↔ Host ブリッジ

syscall / Mach trap を境界とし、

ユーザー空間のx86コード（メインバイナリ+ dylib）は全てARM64に変換、翻訳して実行
カーネルへの問い合わせが必要な瞬間（syscall、Mach trap）だけホストネイティブ(rustmute-runtime)に渡される

syscallとMach trapは別々のディスパッチに振り分けられる
rustmute-runtimeの命令実行ループ（ランループ）は、syscall/Mach trapに遭遇すると制御を取り戻し、ホスト側ハンドラを実行後、ゲストを再開する。
メモリモデル… x86_64とホストの仮想アドレスは1:1マッピングされる。
ゲストはx86_64、ホストはARM64なのでゲスト向けに嘘の情報を返すこともある。

（ここはLLMのコピペ＆Claudeで図を作成）：

計算ロジックは翻訳済みARM64コードとして完結させたまま、「OS・カーネルとやり取りする瞬間」だけホスト機能を呼び出し、その結果をx86的なレイアウト・値に変換してゲストに返す、というのがブリッジの基本設計です。

例外／シグナル／フォールト

基本

ゲストコードが例外（未対応命令、不正アクセス等）に遭遇すると、ランループに制御が戻る。

シグナル

ゲストでの sigaction で登録されたハンドラをホスト側で保持される。
同期と非同期シグナルの区別。
ランループでホストに制御が戻り、ホスト側のハンドラを実行している。

ページフォールト（ここはLLMのコピペ）：

  ARM64 生成コード（メモリヘルパ）
    null/OOB アクセス検出
    → PENDING_MEM_FAULT に詰めて即 return（panicしない）
          ↓
  JIT run() ループ（ブロック実行直後、毎回チェック）
    take_pending_mem_fault() で検出
    → get_sig_disp(11) でハンドラ有無を確認（runtime のグローバル表）
          ↓
    ハンドラあり: deliver_signal(11, rip)
      → ゲストスタックに siginfo_t/ucontext_t 構築
      → SIG_RETURN_ADDR を仕込んでハンドラへジャンプ（SyscallResult::Redirect）
      → ハンドラ ret 時に run() が sig_stack から元の文脈を復元
    ハンドラなし: exit(139)  ← 実機の SIGSEGV デフォルト動作を模倣

ポイントは、実際の ARM64 MMU フォールト（W^X やマップ外アクセス）ではなく、ソフトウェアでの範囲チェックを使って意図的にSIGSEGV相当の状況を作り出している点です。これにより Rust 側で panic/unwind することなく、x86ゲストにとって自然な「SIGSEGVが配送される」という観測結果を再現しています。

Mach trap （Machのシステムコール）

macOSはBSD系のUnix syscallだけでなく、 Mach(XNU カーネル)由来のMach trapというシステムコールを持っている。それをrustmute-runtimeではsyscallと並べてMach trapを処理するコードを書いている。

メモリオーダリング (TSO)

時間が足らずTSO(Total Store Ordering)の実装は非対応。

x86_64 … TSO(Total Store Ordering) を採用
ARM64 … 弱いメモリ順序

バイナリトランスレーションで、x86_64命令をARM64命令に1対1で変換しているだけだと、ロック処理、並行処理に依存したコードで異なる挙動を示す可能性がある。そこで、Apple SiliconではTSOにメモリモデルを切り替える命令があるらしい。

参考:

IR の設計

IR(Intermediate Representation 中間表現)について説明する。 IRの意義は、バイナリトランスレーションのような異なる表現間（今回はCPUアーキテクチャ。プログラミング言語でもいい）において、共通の意味表現を提供し、今回は命令の実行やコード生成、そして最適化を実現することにある。

例えば、「x86_64 → IR → JIT(ARM64)」「x86_64 → IR → AOT(実行ファイル)」のように、共通のx86_64から異なるバックエンド（JIT, AOT）を生成するための独自表現として今回のIRは利用される。

今回のIRコンポーネントは表現の提供以外に、以下の特徴を持っている。

フラグの遅延評価 … 後述する「デッドフラグ除去」が可能になる。
x86の加減算のように桁上がり下がりのキャリーを保持した細かい表現を、IRで実現している。
JIT/AOT 共有 … 一度フロントエンド（decoder）を書けば、JIT/AOT両方で利用できる。

最適化のパターン

バイナリトランスレーションやJITにおける最適化はいくつかある。初期実装と、後から実装に加えた物それぞれ示す。

初期からあるもの
- 命令キャッシュ … 逆アセンブルしてARM64コードに変換済みの命令列をキャッシュする。 HashMapで1探索で完了する。アドレス単位で探索。
- レジスタ読み書きの関数呼び出しを当初していたが、相当する命令に置き換えたことによる高速化。
後から追加のもの
- デッドフラグ除去 … フラグレジスタへ出力する命令でも、後続でフラグが入力されていない・使われていないなら計算は無駄となる。これをIRレベルで除去する。
- レジスタのdead code 除去(dead code elimination) … 短時間で終わるプログラムでは最適化が逆に時間を食っているかも。
今回、実装を見送ったもの
- ブロックチェイニング … 分岐先へ直接ジャンプしてディスパッチ往復を省くもの。自己書き換えコード（SMC）への対応にも追われそうで、修正規模の割に（今回の実験的な実装での）メリットがなく未実装。

今回実行したファイルは最適化ビルドされたものであるため、バイナリトランスレーション後に最適化が効く余地は狭いのでは、という話もある。

実装・デバッグのアプローチ

主にClaude Codeでのやり方を書くが、人間がやってもおよそ同じやり方をとると思う。

ローダーやランタイムをギリギリ動かす最低限繋げる／主要な命令（加減算や条件分岐など）も実装する
代表的なプログラム（CLIで、echoなど）を動かす
未実装のx86_64の命令あるいは実行結果やエラーや正常終了するまで動かす
結果（出力、エラー）が出たらデバッグ（命令を実装したり失敗箇所を修正する）／成功したら2で別のプログラムを実行する

要は、バグが出なくなるまで色んな実行バイナリを食わせてぐるぐるデバッグと実装を回す方法である。人間がバイナリトランスレータなりエミュレータなりを実装する時もこんなアプローチだと想像できるが、これは結構Claude Codeと相性が良かった（トークンを消費するが）。

動作させた実行ファイル

完全動作かは別として、起動・実行を確認した代表例。

tar, gzip, bzip2, zip, sw_vers, seq, ls, cp, file, sort, curl, textutil

開発中は実装不足だったが、最終的にはおおよそ動作するようになった。

ベンチマーク

md5コマンドの実行時間を紹介する。

$ time ./target/release/rustmute run-with-dyld /sbin/md5 /sbin/md5
[dyld-boot] main binary: /sbin/md5  entry=0x100000680  is_lc_main=true
[dyld-boot] dyld: /usr/lib/dyld  entry=0x4e50
[dyld-boot] KernelArgs.mainExecutable=0x100000000
[dyld-boot] shared cache mapped at 0x7ff800000000
[dyld-boot] starting JIT at dyld entry 0x4e50, RSP=0x7fffffdff320
MD5 (/sbin/md5) = 2e26db32e9d772b7c4551c11977e444e

real    0m0.704s
user    0m0.315s
sys     0m0.387s
$ time /sbin/md5 /sbin/md5
MD5 (/sbin/md5) = 2e26db32e9d772b7c4551c11977e444e

real    0m0.006s
user    0m0.002s
sys     0m0.004s

md5コマンドのファイルは133KBなのでmd5を計算するにしては負荷が小さいく、RustmuteのJITのオーバーヘッドが大きいため、md5計算自体の差は見えない。

ubuntu-24.04.3-desktop-amd64.iso (5.9G)を対象にするとmd5コマンドで12.560s,、rustmuteで306.697s 純粋にCPU負荷のワークロードではまだまだ遅い。

isoイメージは大きすぎたので適当なepub(300MB近い)を使って、実行時間も計測した。

rustmute timings [run-with-dyld]:
  load        :      0.1 ms
  stack-setup :      0.0 ms
  cache-map   :    165.1 ms
  lift        :      7.3 ms   (13699 calls)
  codegen     :    121.0 ms   (13699 calls)
  execute     :  13242.5 ms   (57331408 calls)
  syscall     :    134.7 ms   (73929 calls)
  ───────────────────────────────────
  measured    :  13670.8 ms
  total wall  :  16309.3 ms
  block cache:
    hot hit    :   57317709  (99.98%)
    slow hit   :          0  ( 0.00%)
    cold miss  :      13699  ( 0.02%)
    smc        :          0  ( 0.00%)
    ─ total    :   57331408
  dispatch exits:
    jump       :   57257479  (99.87%)  ← chainable
    syscall    :      73929  ( 0.13%)
    ret        :          0  ( 0.00%)
    trap       :          0  ( 0.00%)
    ─ total    :   57331408  (== execute ✓ )
  chaining estimate:
    loop overhead  :   46.0 ns/iter
    potential save : 2635.2 ms  (= jump × overhead)

改善

Rustの std::time::Instant をコンポーネントの各フェーズに仕込み、実行時間を見えるようにした。
変換した命令のブロックキャッシュにhit/missカウンタを追加した。
ブロックチェイニングの最適化が有効化どうかを出力させた。

今回は結果がすぐ欲しくて雑にカウンタを追加しちゃった（Claudeの言いなり）。

実行結果は想像通り、md5アルゴリズムの実行であるから変換した命令（execute）の実行時間と実行回数が明らかに大きい。命令の変換自体はオーバーヘッドとしては小さいことがわかる。こういう結果を見ながら最適化をしてみたいものである。

参考 - Hot hit, Slow hit, Cold miss

まとめ

バイナリトランスレータの設計、実装についてまとめた。実装の詳細は多く省いたが、内部構造の理解の助けになれば幸いである。

書いてない技術トピック

Claude Code（コーディングエージェント）の力を借りて実装したわけだが、乗り越える必要のあった技術課題、コンピュータアーキテクチャの専門分野がいくつもあったはずである。書き残しておきたいトピックはここで取り上げる。

仮想メモリの実現方法
プロファイル
- ベンチマークのところで少し取り上げたが、Rustmuteの各機能ごとの実行時間の測定。これによりオーバーヘッドの切り分けも可能になる。
- キャッシュの性能、ヒット率、ミス数の計測。次に実行する最適化の有効性を確認することもできる。

将来の展望

試しに作ったバイナリトランスレータであるが、意外とCLIなどはサクサク動いたのであった。色んな制約から今すぐは実装しないが、作ると面白そうなものを次にあげる。

アンチウイルスのサンドボックス
フロントエンドでのARM64命令の対応
開発ツール（Valgrindもどき、プロファイラ、仮想マシン技術を応用して何か）

バイナリトランスレーションがなければ、ほぼx86_64向けエミュレータ兼macOS ローダー及びランタイムである。

コーディングエージェントでソフトウェアが簡単に作れる時代ではあるが、設計とアーキテクチャ学習を繰り返し、人の手でアイディアやPoCの実現を加速させたい。

ウェブ上の資料

まずは基本的（公式あるいはWikipedia）の資料に頼るつもりで、他の資料に頼らず作成、執筆した。参考にはなるはず。

https://ffri.github.io/ProjectChampollion/ … reverse-engineering results of Rosetta 2
https://github.com/Inokinoki/attesor … AI-powered reverse-engineering of Rosetta (2 for Linux). Disclaimer: due to the user agreement, I will not touch the code. All is done by AI, so there might be messy implementation.

キーワード

shim 方式 … ゲストがライブラリやシステムコールを呼ぶ際に、ホストの薄いラッパーを呼ぶ方式のことをこう言うとか（ウェブで資料が出てこない）
SMC(Self-Modifying Code): 自己書き換えコードのこと。実行時にプログラムがCPUの命令を生成したり、命令にパッチをあてたりすることがある。例えばパフォーマンス目的で、今回のようにJITコンパイラなどを作る場合。また、アンチデバッグ技術として実行ファイルの解析をしづらくさせるために自己書き換えを行うこともある。
Lift, Lifter: 上位へ持ち上げるという意味で、機械語→ IR などが例となるらしい。逆方向がLower。
Lower: Lift, Lifterとは逆に IR → 機械語というようにより低レイヤのこと。ロワリングは低レイヤへ変換すること。

おまけ - コード行数

create内のコード行数の一覧

$ wc -l `find crates/ -name "*.rs"`
crates/rustmute-jit/tests/dynlink.rs
crates/rustmute-jit/tests/threads.rs
crates/rustmute-jit/src/lib.rs
crates/rustmute-jit/src/futex.rs
crates/rustmute-ir/src/types.rs
crates/rustmute-ir/src/flags.rs
crates/rustmute-ir/src/lib.rs
crates/rustmute-ir/src/block.rs
crates/rustmute-ir/src/instr.rs
crates/rustmute-interp/tests/interp_basic.rs
crates/rustmute-interp/src/flags.rs
crates/rustmute-interp/src/lib.rs
crates/rustmute-interp/src/interp.rs
crates/rustmute-arm64/src/flag_dce.rs
crates/rustmute-arm64/src/regalloc.rs
crates/rustmute-arm64/src/lib.rs
crates/rustmute-arm64/src/helpers.rs
crates/rustmute-arm64/src/abi.rs
crates/rustmute-arm64/src/lower.rs
crates/rustmute-aot/src/lib.rs
crates/rustmute-runtime/tests/execution.rs
crates/rustmute-runtime/src/native.rs
crates/rustmute-runtime/src/lib.rs
crates/rustmute-runtime/src/shims.rs
crates/rustmute-decoder/tests/lift.rs
crates/rustmute-decoder/src/lifter.rs
crates/rustmute-decoder/src/lib.rs
crates/rustmute-decoder/src/regmap.rs
crates/rustmute-cli/src/main.rs
crates/rustmute-cache/tests/parse_x86_cache.rs
crates/rustmute-cache/examples/symbolize.rs
crates/rustmute-cache/src/error.rs
crates/rustmute-cache/src/lib.rs
crates/rustmute-cache/src/header.rs
crates/rustmute-cache/src/exports.rs
crates/rustmute-cache/src/image.rs
crates/rustmute-cache/src/mapping.rs
crates/rustmute-core/src/cpu.rs
crates/rustmute-core/src/error.rs
crates/rustmute-core/src/lib.rs
crates/rustmute-core/src/memory.rs
crates/rustmute-loader/tests/load_macho.rs
crates/rustmute-loader/examples/disas.rs
crates/rustmute-loader/examples/readstr.rs
crates/rustmute-loader/src/cache.rs
crates/rustmute-loader/src/lib.rs
crates/rustmute-loader/src/macho.rs
crates/rustmute-loader/src/dyld.rs
crates/rustmute-loader/src/fat.rs
crates/rustmute-loader/src/stack.rs
crates/rustmute-loader/src/loader.rs
crates/rustmute-loader/src/shims.rs
total

バイナリエディタPheasant v0.1.0 リリース

Mon, 23 Mar 2026 13:21:20 +0900

バイナリエディタPheasant v0.1.0をリリースしました。

1. これは何か

PheasantはRust製のバイナリエディタで、GPUアクセラレーション描画で大規模ファイルも軽快に動作可能です。 Claude Codeでコードを生成して作りましたが、設計だけでなく実装レベルでレビューが入っています。

https://github.com/suma/rusthex/releases/

2. なぜ作ったか

近年だとリッチな機能を持つバイナリエディタもありますが、私がバイナリエディタを作ろうと思ったのは約20年前にもさかのぼります。

大きなファイルでの動作速度を確保し、クロスプラットフォームに対応したエディタ当時は珍しかったのです。

そういう理由でアイディアは持っていたものの、過去に開発途中で投げだしたことはあり、Claude Code (Opus 4.5)の出現によって再度開発するモチベーションがわいてきました。2025年12月のことです。自分用とはいえ半分趣味ではあります。

3. Pheasantの主な機能

ファイルを眺める: 巨大ファイル対応（メモリマップ）、ビットマップ可視化で全体の構造を俯瞰
- 巨大なファイル対応は、Piece Tableと呼ばれるデータ構造でドキュメントを表現します。これにより巨大なファイルの挿入、削除、上書きに対応しつつも、高速な画面のスクロールも可能になります。
検索・ナビゲーション: マルチスレッドでUIとは別スレッドで高速検索、ワイルドカード対応、ブックマーク機能
- モダンなエディタっぽく仕上げるために、検索だけでなくブックマークやカーソルの履歴も保持するようにしました。
AI連携: 選択範囲をOllamaなど外部コマンド(LLM)にパイプして解析可能、MCPサーバーでClaude Codeから直接バイナリ操作
- かなり実験的な機能で、今後どうなるか未定ですがLLMと接続してバイナリエディタ自身を拡張できるようにしています。といっても現段階ではログ画面に解析結果を表示するだけとなっています。

4. AIとの連携

AI(LLM)を用いたバイナリ解析というのは今後主要なトピックになっていくと考えています。そんな中、バイナリエディタとしてできるアプローチとしては次の2点が筋が良いと思っています。

外部のLLMをエディタから呼び出す 前述したOllama連携(外部コマンド呼び出し)がこれです。
- どうしてもバイナリエディタ側の機能は少なくなる、あるいはPython拡張のようなアプローチにせざるを得ない状況になるのではないかと思います。そんな中、LLMは光明かもしれません。少なくとも現状は、「ヒント」を外部からもらうためのインターフェースとしてコマンドラインで外部にデータ解析を投げるだけです。解析する主体は人間にあります。
MCPサーバー LLM側からバイナリデータを読み書き、解析するというアプローチです。
- これはもう解析の自動化、あるいは解析する主体を人間(バイナリエディタ)から機械(LLM)へ移すという流れになります。現在のLLMの流行を考えると、こちらのアプローチも強くした方がいいかもしれません。実験的な機能なため、ドキュメントもあえて整備していません。

5. 今後の予定

バイナリ解析はどうなってしまうのか、という情勢ではありますが、まずは気軽に解析するためのアプローチとしてこちらのバイナリエディタPheasantを触ってもらえると嬉しいです。

https://github.com/suma/rusthex/releases/

2025年を振り返りつつ、2026年やりたいこと

Sat, 03 Jan 2026 13:20:00 +0900

あっという間に2026年

2025年を振り返りつつ2025年やりたいこと、学習したいことについて書く。

2025年で買って良かったもの

Technicsのイヤホン EAH-AZ100
組立代行へ発注したPC
- Radeon RX 9070 XTの発売にあわせたが、今のRAM不足を考えると、値下がり具合も含めタイミングが良かった
ひげ脱毛を始めた（物ではないが）
- 日々の生活でのひげそりが格段に楽になった（肌荒れも減少）
- 少し若返った印象

読んで良かった本

昨年もその傾向はあったが、集中力、読むスピードは明らかに鈍くなったなという印象。年かな。

心に残っている本をこちらにリストアップする。

『メダリスト』
- 情熱を感じる
『時計の科学　人と時間の５０００年の歴史』
『世界一わかりやすい腕時計のしくみ』
- 某友人が機械式腕時計にハマっていて、話を聞いたりして私は機械式の仕組みに興味を持った
『ソフトウェアエンジニアガイドブック』
- キャリアもそうだし、ソフトウェアエンジニアとして技術のキャッチアップにも良さそう

書籍ではないが、映画の「国宝」は良かった（2025年ベスト映画）。

2025年やったこと、行った場所

6月大阪・関西万博へ
9月星景写真を撮影しに神津島へ旅行
LLM（生成AI）のコーディングエージェントが活躍（私的にも業務でも）
- 2025年は生成AIが大躍進した年だと思う
コンパイラ学習（実装）を進めることができた。
- 今まではパーサーの実装途中だったが、Claude Codeにより言語としてのフロントエンドの部分に加えて、インタプリタの実装も進められた
- コーディングエージェント（Claude Code）の働きが大きい
- フロントエンド（主にパーサー部分）にこだわるつもりはなかったが、想像以上に力を入れてしまった

2026年挑戦したいこと

コンパイラ最適化について学ぶ
- 2026年は友人とオンラインで一緒に学習する集まりを開くことになった
- 欲しいアウトプット
  - コンパイラのコード生成器を実装する
  - 学習した結果をまとめる（ブログなど）
継続してコンパイラの実装活動
- アウトプット
  - ブログ、実装の公開（GitHub）

ウェブサーバーでBrotli圧縮を有効化した

Sun, 07 Dec 2025 23:50:00 +0900

はじめに

ちょっと前に次のエントリを読んだ。Zstandardは知っていたが、Brotliという圧縮アルゴリズムはその時知らなかった。BrotliもZstandardもどちらももう10年近く前に発明された圧縮アルゴリズムになる。

圧縮アルゴリズム比較: gzip・Deflate・Brotli・Zstdの実用性と進化

静的ページなので事前圧縮を採用！

せっかくなので、このobfuscatism.netをホストしているウェブサーバーもBrotli対応しようと考えた。調査した結果、静的ページしかないので次の前者を選んだ

あらかじめファイルを圧縮(pre-compression)しておき、アクセスがあったとき圧縮済みのファイルを転送させる。静的ページに有効
Apacheでのmod_gzipのように、動的にアクセスされたファイルを圧縮して転送する。mod_brotli（Apache）や、brotli on;（nginx）オプションなどがある

後者は動的コンテンツなどに有効であるが、オンザフライで圧縮がかかる（圧縮済みのデータはキャッシュされないはず）ため静的コンテンツのみの場合にCPUリソースを余計に消費してしまう。

Claude AI曰く、最低1KB以上のファイルが圧縮に適しているらしい。小さすぎるとオーバーヘッドが大きいというのもなんとなくわかる。

Apache 2.4に適用

静的コンテンツの場合、mod_rewrite などでリクエストを書き換えたりしたのであるが（gzipで伝統的なやり方の様子）、mod_filterで AddOutputFilterByType DEFLATE といったファイルを他より先に圧縮していて中々Brotli圧縮済みのファイルが転送されずに困るといいうこともあった。最終的には無事Brotliも有効化できた。

まとめ

Chromeの開発ツールなどを見て、Brotli圧縮済みのファイルが転送されていたり、転送速度も確認できて満足だった。しかし、obfuscatism.net自体すごく軽いウェブサイト、ブログなのでgzipで事足りるという説もある 😇

ほぼ自己満足ではあるが、採用できて良かった。爆速になったかは定かではない。。。

言語処理系を作っていたとき考えていたこと

Thu, 11 Sep 2025 20:40:00 +0900

はじめに

Rustで言語処理系を作ってみるという試みの続きである。どこにこだわり、どういう理由でそんなプログラミング言語の文法及び実装にしたのかということについて記述する。

設計、こだわりポイント

言語
- 静的型付け言語
syntax
- Go, Python風に改行で1文を区切る
- if/else/whileなどの条件の括弧() は省略したい
  - GoとかRust風
  - 追加のトレードオフ： if variable_name { の variable_name { が構造体リテラルに誤認識してしまった。パーサーの追加修正あり
- if/elseには必ず {} を付ける
  - 追加のトレードオフ
    - elifキーワード (else if)の導入
    - if x {} else { if y {} } のようなコードを防ぐため
- 型推論
  - val, var の型宣言を省略可能。また、後続の変数（代入など）から型推論できる
  - Rustっぽいですね
- エラー処理
  - 文法や型チェックでエラーが出たとき、エラーの位置を表示できる
  - エラーレポートの表示（行番号、位置）
内部構造
- パーサーでは再帰を多用しているが、無限再帰に陥る可能性がある。無限再帰予防の措置（カウントしている）がある
- String interningの利用。ソースコード中には、変数や関数などのidentifier、文字列リテラルなどあらゆるところでキーワードトークン以外の文字列が出てくる。そこで、文字列はSymbol(int型とか)で表現することで格納・比較がやりやすくなる。メモリ消費量も抑える（可能性がある）ことができてお得だ。
将来
- エラー処理のためにトークン及びASTレベルでコードの位置情報を保持しているが、LSP対応とかlinterとか考えると保持する利点はありそうである。
- Frontendは並列化（マルチスレッド化）したいとかそういう野望もある。現状は、String interningや型チェック時のシンボル探索などをどう並列化するとよいか考え中でもある。しかしClaude Codeがサクッと答えを出してきそうなポイントでもある。
  - Claude Codeによると、Rust (rustc), TypeScript Compiler (tsc), Go Compiler - パッケージレベル, Swift Compiler - ファイルレベルなどで並列化をサポートしているらしい。

実装・コンポーネントレベルのはなし

Rustの実装レベル、コンポーネントレベルでどのようにしているか書く。

Lexer
- 以下のトークンに分割するのがLexerの役目。
  - キーワード、コメント、数値リテラル、文字列リテラル
- すべてのトークンは文字列の位置情報を持っている。たしか、ソースの文字列の開始位置とその長さを持っていたと思う。
Parser
- 当初はすべて手書きだったが、気づいたらClaude Codeに書き換えられていた。ちょっとむなしい。
- 再帰下降パーサーであるが、再帰の箇所では上に書いたように再帰回数のカウントがあり、スタックオーバーフロー防止になっている。Claude Codeの実装になるのと、そんな難しいアイディアではないが初出はどこだろうね。
- 文法エラーの複数取得は意外と簡単なところもあり、次に出現するトークン（予定）と違ったらエラーではあるが、そこはエラーは無かったことにして後続の処理へ続けさせ、1個でもエラーが貯まっていれば文法エラーがあると判別できる（理論上は、、、もうちょっと難しかったかもしれない）。
TypeChecker
- TypeCheckerという仰々しい名前ではあるが、以下の機能も行っている。
  - 型チェック
  - 変数の存在管理（寿命、スコープ）
  - モジュールのインポートとそのシンボル管理
  - ビルトインのモジュール・関数の提供
Backend
- Interpreter (走査=walkで、AST walk interpreterと言う分類らしい)
  - バックエンドを実装したとき、モデルケースとなる正解のインタプリタがあると便利だろうと思い作成した。
  - 実際のところ、自分では使わないがテストを作って実行するのに非常に役に立つ存在となった。また、ベンチマークにもよく使っている。
- Lua backend
  - 作りかけ。luaファイル（テキスト）を生成する
  - 特にLua JITではビット演算のオペレーターがなかった（たぶん）ため、ビット演算をLua JIT提供のライブラリを使うことができるようにした。もしくは、Lua標準の機能を使うか、コード生成時にを使うか切り替え可能なバックエンドにしている

まとめ

雑に整理してみたが、こんなことを考えたり試行錯誤しながら実装していた。

Rustで言語処理系を作ってみるという試み

Wed, 10 Sep 2025 23:40:00 +0900

はじめに

Rustでプログラミング言語の処理系（toylang：名前は未定のまま引きずっている）を作成した。厳密には作成途中ではあるが、その経過や設計について書きたいと思う。

https://github.com/suma/toylang

最初に断っておくと、私はプログラミング言語や型システムの専門家ではない。アマチュアである。また、これは趣味の活動によって開発された（厳密には、「されている」）ソフトウェアである。業務で開発した物ではない。

趣味とはいえ、私はソフトウェアエンジニアとしてのプロの経歴が10年以上になる。実装レベルで手抜きをしてしまってる箇所も幾分あるが、今回作成した処理系の設計・デザインチョイスといった部分では、こだわり・挑戦してみたいことなどを優先している。といっても、試行錯誤のひとつなので特別お気に入りでない限り特筆しない。また、こだわりだけではいっこうに開発が進まなかったため、実用レベルのソフトウェアを開発する気概を持ちつつも、途中からClaude Codeの利用が始まると妥協を多く入れていった。まぁ、何しろ言語処理系を作るのはかなり筋肉（と表現させてもらう）が要るからね…。

作った言語について

言語仕様は、Rust, Go, Pythonなどからいいとこ取り、気に入った文法や機能を試しに実装している段階にある。繰り返しになるが、まだ開発中である。

将来的にはLLVMバックエンドなど作りたいところであるが、いまはフロントエンドやインタプリタを作って動作確認・お試しをしている段階にある。

フロントエンドは何でもよいとか、LLMで生成するからなどという説があるかもしれないが、UXであるとか、DSLとしての使い方など、見た目（文法）はこだわれるポイントである。 LLM（コーディングエージェント）が存在するからといって、オフライン環境ではローカルLLMが必要になるだろうし、ネット上に存在しないハードウェアのソフトを実装するとしたらどうなるだろうか。

スタート地点 rflex

詳しくは Rustでコンパイラ作り part1に譲るが、自作のコンパイラを作りたいと2019年頃から考えていた。その頃からパーサは手書きにすると決めていたため、せめてLexer生成器だけは自動生成にしようとrflexを作成した。

再帰下降パーサとFlatten AST

再帰下降パーサを書く時点からFlatten ASTな形式であると決めていた。ふつうAST（抽象構文木）を木構造で表現するが、実装上は配列に格納する形としていた。木構造を表現しなくていいため、そのためのオーバーヘッドや、配列形式によるメモリキャッシュの活用が想定された。

再帰下降パーサで文法を記述するのに、約2,3年はかかった。理由は難しかったからではなく、実装の手間が大きかったことによる。文法が定まってない間は、よい子は余り真似しない方がいいかもしれない。

転換点 1. Claude Code

再帰下降パーサで文法をおおよそ定義出来てきた頃、Claude CodeなどのAIエージェント（コーディングエージェント）が流行りだした。これは良いと私も採用を決定し、手書きのフロントエンド（再帰下降パーサ、型チェッカー）などの書き換えが進んでいった。インタプリタもほぼClaude Codeを利用した気がするし、README.mdもである。

LLM(Claude Code)の利用テクニックはここで書いても仕方ないと思うが、気にしていた点として、以下の点があげられる。

コンテキストは長く持たない（ /clear コマンドを利用する）
コードが複雑になる前にリファクタリングをする
サブエージェントの活用(git-add, git-commitを作成した)
Enter連打（あるいは自動）でコードを入力させ、早く実行させたくなるが、Claude Codeが作成したコードの意味をなるべくたずねる、設計上の選択を聞く、オススメの選択を聞くといった行動をとること
転換点 2. Structure of Arrays

SNS上でData Oriented DesignとZig言語、その実装パターンであるStructure of Arraysに感銘を受け、ASTのデータの持ち方をFlatten ASTから変更した。

リファクタリングにもClaude Codeを使った。フロントエンドのパース、型チェックの速度はベンチマーク上で約20倍にもなったので驚愕した。正直なところ実用的なコードが無い以上、ここでベンチマークの結果についてあれこれ語っても仕方ない面もあるが、コンパイラという種類のソフトウェアの設計（実装パターン）でさえ10倍以上の速度差が出ることについて、やっぱりソフトウェア開発は面白いなと思った。

まとめ（現在・未来）

こだわりの機能としては、

配列のスライス (絶対欲しい人がいる、自分では使わないがそう思った)

お試しで作ってみたのは、

Lua backend
Generics

Claude Codeの甘言に乗せられてしまい、関数と構造体にGenerics機能を追加してしまった。型チェッカーが重くなり、型推論も時間がかかっているはずである。

本当はこだわりポイントとか語って気持ちよくなろうと思っていたが、表層をなぞるだけで自分がお腹いっぱいになってしまった。本当にプログラミング言語として成功するには、FFIやツールチェインも必要そう。もしくは、ゲームエンジンに採用されるようなアプローチ（としてLua backendありかなと試しに作った）も考えられるかもしれない。

まとめると、まずは自分が心地よいコードを書けて、なおかつ近年の研究課題などもアプローチできるとなお面白いんじゃないかと思う。

課題

言語組み込みの関数、クラスを作るのは課題である
- なるべく楽に言語処理系内に組み込みたいというモチベーション
- FFIを上げたが、外部ライブラリとの連携も肝である
研究っぽい難しい課題にチャレンジするとなお面白いかも

参考

ウェブ

書籍

他にもたくさん書籍はあるが、開発中に読んだものとして、

Rustで作るプログラミング言語 —— コンパイラ／インタプリタの基礎からプログラミング言語の新潮流まで

続編

言語処理系を作っていたとき考えていたこと

2024年振り返りと、2025年やりたいこと

Tue, 31 Dec 2024 16:30:00 +0900

2025年目前

今年も色々ありました。たいしたことはないけど、プラモデル（ホワイトグリント）を組み立てたり、業務では引き続きウェブサービス開発をやったり、年末には業務に関係なく色彩検定3級を合格したりしました。

目標の達成具合

以下上2つは2024年の目標だった。これを含めて2025年は継続しつつ色彩検定の学習もやっていきたい。

ピアノ練習 10-30分（継続）
- 毎日のうちたまに忘れることもあるが、ほぼほぼやってる
週2回、土曜と水曜のジョギング（あるいは片方を筋トレ） 10-30分
- これも完全に習慣化できてるわけではないが、ウォーキングを混ぜつつ運動習慣になりつつある
色彩検定2級を取る

できなかったこと、努力が足りなかったのは次の2点。

Kovaak …. ゲーム自体のプレイ時間が少なくなったため中止
プログラミング … 趣味時間ではあまり集中してできていない

2024年買って良かった物

必要にかられて買った物はいくつかあるが、特に良かったと感じたのは以下の製品。

HITACHI パワーブーストサイクロン　コードレススティック型掃除機
- 吸引力が強いのは正義かな、と思った
- オプションパーツのホースなどにもLEDが付いてたりして、かゆいところに手が届く
イヤホンSeeAudio Yume Ultra
- オーディオ用イヤホンのリプレースとして。AliExpressで初めて買った製品
- 今年前半はイヤホン沼に入門していた。すぐ抜け出した

2024年ベスト書籍

夏目漱石『こころ』
- ふと読み直したくなり
『ありす、宇宙までも』
- この漫画が凄い（個人的に）
藤井太洋『マン・カインド』
『ヴィクトリア朝時代のインターネット』
- 電信にまつわる歴史と物語かな、ノンフィクション

読み途中だけど『2030半導体の地政学』と『AI覇権　4つの戦場』もなかなか良い気がする。

2025年やりたいこと

目標に加えて、

新PC調達、Ryzen 9900Xかなぁ。今時点でGPUは新製品待ちの状態
引き続き言語処理系関連とRustでの実装

に挑戦していきたい。

色彩検定3級を受験してきた

Fri, 20 Dec 2024 23:30:00 +0900

先日、色彩検定を受験し、3級に合格した。

きっかけ

よく行くアパレルショップの店員さんが「ぼくカラーコーディネートの資格持ってるんですよ」と言っていて興味を持った（3年以上前）
池袋ジュンク堂に行ったとき、偶然「色彩検定」の公式テキストを見つけた（1年以上前）

ちなみに業務には直接関係ないため、合否は特に業務範囲等に影響しない（けど役立つ可能性はあり）。

受験と対策

2, 3級はマークシートで、1級は二次試験で筆記があるらしい。マークシートに備えて久しぶりにシャーペン（マークシート用）を購入した。

公式テキストに加えて参考書を2冊購入してのぞんだ。

過去問をやって難易度はわかっていたが、3級だと2週間程度（平日は仕事あり）の暗記でなんとかなった（個人差があります）。

その他

家族に報告したら業務に関係なく姉も合格していることが発覚（しかも2級）。意外と狭い世界なのかもしれない。

将来

2級までは取得してもいいかもしれない。また、せっかく勉強しているので写真撮影やウェブデザインなどにスキルを活かしたいところである。

プラモデルのホワイト・グリントを製作した

Thu, 18 Apr 2024 20:30:00 +0900

ARMORED CORE for Answerというゲームに登場するロボット（機体）であるホワイト・グリントのプラモデル（コトブキヤ）を製作した。ゲーム自体は2010年頃（訂正）にPS3でプレイしていたが、プラモデルは2014/06/07に購入してそこから製作を始めた。途中何度も組み立てる気力を失っていたが、今年に入りようやくホワイト・グリントが完成した。

パーツとパーツの合わせ目が粗かったりすることもあるが、遠くから見る・撮影する分にはそれなりに見える。

感想としては長かった。プラモデル作りは予想以上に工程があり、明示されてもいないので大変だった。世のプラモデル好きな人はよくやるな、と思った。まぁ自分自身もそれに含まれてしまうのだけれど。

次何か作る時はもうちょっと丁寧に作りたい。せっかく製作したので、一応ブログに書いて供養しておく。

obfuscatism

2026年、Amazon Kindle Scribe を買う

Kindle Scribe の特徴

Oasis比体感スピード

プレミアムペンでの書き心地

最後に

x86_64→ARM64 バイナリトランスレータの設計と実装

はじめに

モチベーション

設計の開始

全体

設計

プロジェクトの構成

各コンポーネントの依存

実装

Loader

Loader その2 (dyld)

Decoder その1

Decoder その2（Lifter）

ランタイム・JITエンジン及びsyscall

Guest ↔ Host ブリッジ

例外／シグナル／フォールト

Mach trap （Machのシステムコール）

メモリオーダリング (TSO)

IR の設計

最適化のパターン

実装・デバッグのアプローチ

動作させた実行ファイル

ベンチマーク

まとめ

書いてない技術トピック

将来の展望

ウェブ上の資料

キーワード

おまけ - コード行数

バイナリエディタPheasant v0.1.0 リリース

1. これは何か

2. なぜ作ったか

3. Pheasantの主な機能

4. AIとの連携

5. 今後の予定

2025年を振り返りつつ、2026年やりたいこと

あっという間に2026年

2025年で買って良かったもの

読んで良かった本

2025年やったこと、行った場所

2026年挑戦したいこと

ウェブサーバーでBrotli圧縮を有効化した

はじめに

静的ページなので事前圧縮を採用！

Apache 2.4に適用

まとめ

言語処理系を作っていたとき考えていたこと

はじめに

設計、こだわりポイント

実装・コンポーネントレベルのはなし

まとめ

Rustで言語処理系を作ってみるという試み

はじめに

作った言語について

スタート地点 rflex

再帰下降パーサとFlatten AST

転換点 1. Claude Code

転換点 2. Structure of Arrays

まとめ（現在・未来）

課題

参考

ウェブ

書籍

続編

2024年振り返りと、2025年やりたいこと

2025年目前

目標の達成具合

2024年買って良かった物

2024年ベスト書籍

2025年やりたいこと

色彩検定3級を受験してきた

きっかけ

受験と対策

その他