**Z80 Sans – フォントで実装したディスアセンブラ (2024)**

2026/03/05 11:38

**Z80 Sans – フォントで実装したディスアセンブラ (2024)**

RSS: https://news.ycombinator.com/rss

要約

Japanese Translation:


Summary

Z80 Sans は、Hexadecimal Z80 命令バイトを GSUB と GPOS テーブルを介して視覚的なグリフに変換するカスタム OpenType フォントです。プロジェクトは

instructions.json
ファイルを解析し、最大 458,752 個のユニークグリフ(各々が特定のバイト列を表す)を生成し、それらを小文字エンディアン順序、符号付きオフセット、および 65,536 グリフ制限に従うルックアップチェーンに配置します。

FontForge(Ruby インターフェース経由)で

commit 4f4907d9…
から構築され、フォントは WOFF2 としてエクスポートされます。OpenType 機能をサポートする任意のプラットフォームで使用できます。事前ビルドされた
z80-sans.ttf
は速やかなテスト用に
./test/
ディレクトリで利用可能です;ビルド後、生成された
.ttf
~/.local/share/fonts/
にコピーされます。

インストールには Debian GNU/Linux 12、Ruby 3(

fontcustom
がこのバージョンと互換性がないことに注意)、OpenSSL、ImageMagick、potrace、および
fonttools
が必要です。ビルドプロセスは WOFF2 をコンパイルし、RVM 2.4 のローカル OpenSSL インストール下で Ruby gem
fontcustom
をインストールします。

設計上の課題は、再帰下降パーサーを通じてすべてのオペランド可能性を Hex バイト列に展開し、それらをグリフへマッピングすることで対処されます。コンテキスチュアルチェーンルールは、

SET b,(IX+o)
SRA (IX+o)
のような順序外のオペランドを、最後まで Hex バイトに一致させ、それぞれの変種用に専用ルックアップを生成して処理します。

既知のレンダリング不具合には、

LD (IX+o),r
での間隔が不正確な点と
SET b,(IX+o)
におけるコンマが欠落している点があります。これらは「CTF quality」の小さな問題であり、全体的な機能には影響しません。

将来の改善としては、FontForge のスクリプタブル機能生成(

GenerateFeatureFile()
MergeFeature()
)を活用するか、Harfbuzz WASM を探索してさらに複雑な命令セットを処理できるようにすることが考えられます。フォントのベースグリフは Droid Sans Mono(Apache ライセンス)と Noto Sans Mono(Open Font License)から取得され、命令セットデータは
maziac/z80‑instruction‑set
から取得されています。

Z80 Sans は、低レベルの Z80 エミュレーション開発者や教育者が分解されたコードを明確に視覚的に表現したい場合に特に有用であり、カスタムフォントがニッチなアプリケーション向けに広範なバイナリ語彙をエンコードできることを示しています。

本文

Z80 Sans – ディスアセンブラフォント


何をするのか

Z80 Sans は16進数バイト列を読みやすい Z80 アセンブリに変換します。
OpenType の GSUBGPOS テーブルを使って、各ニブル(0–f)を 命令語・レジスタ・アドレス・オフセットを表すグリフへマッピングします。

「好きなディスアセンブラは? それはフォントです。」


クイックインストール (Debian 12)

# 依存関係
apt install imagemagick potrace
pip install fonttools

git submodule update --init --recursive

FontForge

cd ./modules/fontforge/
git checkout 4f4907d9541857b135bd0b361099e778325b4e28
git apply ../../resources/fontforge.diff
mkdir -p build && cd build
cmake -GNinja ..
ninja
ninja install

woff2

cd ./modules/woff2/
make clean all

fontcustom (Ruby 2.7 必須)

rvm use 2.7
rvm pkg install openssl
rvm install 2.4 --with-openssl-dir=$HOME/.rvm/usr
gem update --system 3.3.22

export PATH=$PWD/modules/woff2/build:$PATH
cd ./modules/fontcustom/
git apply ../../resources/fontcustom.diff
gem build fontcustom.gemspec
gem install ./fontcustom-2.0.0.gem

フォント生成

cp ./resources/droid-sans-mono.ttf /tmp/base.ttf
./gen.py ./resources/instructions.json
# .ttf は ~/.local/share/fonts/ にコピーされます

デザイン上の課題

課題理由
多くの文字手動 GSUB ルールは非現実的。
巨大な組み合わせ空間一部命令は最大で 65 536 × 7 = 458 752 のバリエーションがある。
オーダー外のオペランドエンコーディングとディスアセンブル時にレジスタ/オフセットの順序が異なる。
リトルエンディアンアドレスLSB グリフを先に表示する必要がある。
符号付きオフセット0x80–0xff のバイトは負の2補数として描画されるべき。

解決策は 再帰下降パーサ で全ての可能なオペランド値を展開し、
得られた命令ごとに1つまたは複数の16進ニブルグリフへマッピングします。


実装ノート

  • 基本グリフ形状は Droid Sans Mono から取得。OpenType テーブルは Noto Sans Mono
    .ttx
    を編集して作成。
  • 文脈チェーンルールで多くのルックアップを処理。
  • 各ニブル(0–f)に独自グリフを割り当て、スペーシング文字で バイトやアドレス全体のマルチグリフ置換を実現。
  • オーダー外ケースは専用リガチャと先読みルールでカバー。

現在確認されている問題

命令表示結果
LD (IX+o),r
LD (IX+o r);
SET b,(IX+o)
SET b,(IX+o));

(これらは軽微な不具合で、残りの ISA は完全にディスアセンブルされます。)


今後の作業

  • 手動
    .ttx
    編集を避けるために FontForge スクリプト (
    GenerateFeatureFile()
    ,
    MergeFeature()
    ) を活用。
  • より大規模な命令セット向けに、Harfbuzz WASM などのフォントシェイパーを検討。

クレジットとライセンス

リソースライセンス
Droid Sans MonoApache License
Noto Sans MonoOpen Font License
instructions.json
GNU LGPL v3
その他すべてのファイルMIT License

ベースフォント: Droid Sans Mono, Noto Sans Mono。
命令セットソース: maziac/z80-instruction-set。


生データをそのまま読みやすい Z80 アセンブリへ変換する、たった一つのフォントでお楽しみください!

同じ日のほかのニュース

一覧に戻る →

2026/03/09 5:30

エージェント・セーフハウス – macOS ネイティブサンドボックスによるローカルエージェントの保護 --- **ポイント解説** - **Agent Safehouse** は、macOS 上で動作するローカルエージェント(バックグラウンドプロセスやサービス)を安全に隔離し、外部からの不正アクセスや権限昇格を防ぐための仕組みです。 - 「macOS‑native sandboxing」は、Apple が提供するサンドボックス機能(`sandbox-exec`, `com.apple.security.*` など)を利用しており、追加のソフトウェアやカーネル拡張は不要です。 **主な特徴** 1. **最小権限で実行** – 必要最低限のファイル・ネットワークアクセスのみ許可し、それ以外は自動的にブロック。 2. **監査ログ** – アクセス試行や失敗がすべて記録され、後からトラブルシューティングやセキュリティ調査に利用可能。 3. **設定の柔軟性** – プロファイルベースでポリシーを定義でき、企業規模に合わせた細かな制御が可能。 **実装例(サンドボックスプロファイル)** ```xml <key>com.apple.security.app-sandbox</key> <true/> <key>com.apple.security.files.user-selected.read-write</key> <true/> ``` このように、エージェント・セーフハウスは macOS の標準機能だけで安全性を大幅に向上させるソリューションです。

## Japanese Translation: > Safehouse は、ローカル AI エージェントがアクセスできるファイルを厳密に制御する軽量な macOS ネイティブサンドボックスです。デフォルトでは「deny‑first」ポリシーに従い、指定されたワークスペース外への読み書き試行はカーネルエラー(“Operation not permitted”)を引き起こし、SSH キーや `.aws` などの機密項目やその他個人リポジトリを保護します。ツールは `curl` を使って `~/.local/bin` にインストールされる単一の Bash スクリプト(`safehouse.sh`)でセットアップされます。 > > エージェントは `safehouse claude --dangerously-skip-permissions` のようなコマンドで呼び出され、現在の作業ディレクトリ(通常は git リポジトリルート)への読み書きアクセスを自動的に許可し、インストール済みツールチェーンへの読み取りアクセスのみを許可して残りのホームディレクトリは拒否します。 > > 上級ユーザーは `safe() { safehouse --add-dirs-ro=~/mywork "$@"; }` のようなシェル関数を `.zshrc` や `.bashrc` に追加し、すべてのエージェント呼び出しがデフォルトで Safehouse 内で実行されるようにできます。セッションごとにサンドボックスをバイパスするには、コマンドに文字列 `command` を接頭辞として付けます(例:`command claude`)。 > > このゼロコンフィグ方式により、開発者やチームはローカルファイルとの AI 連携を安全に行い、個人プロジェクト、クラウド認証情報、企業リポジトリでの偶発的なデータ漏洩を減らすことができます。

2026/03/09 6:40

**ブラックスカイ・AppView**

## Japanese Translation: Blacksky の AppView は Bluesky Social PBC の AT Protocol 参考実装をフォークしたもので、**外部からの貢献やプルリクエストは受け付けません**。すべての変更は `packages/bsky`、`services/bsky` の3つのディレクトリと1つのマイグレーションファイルに限定され、参考コードの大部分を保持しています。 リポジトリは組み込みの TypeScript フィーホーズコンシューマーを Rust ベースのインデクサ **rsky‑wintermute** に置き換えており、並列キューを通じて約10 k+ レコード/秒を取り込むことができます。Wintermute はブートストラップツール(`queue_backfill`、`direct_index`、`label_sync` など)を提供し、ライブインデクシングとバックフィルを分離します。 主なパフォーマンス最適化は次の通りです: - PostgreSQL の LATERAL JOIN 再書き込み(`getTimeline` / `getListFeed` 用) - Redis キャッシュレイヤー(アクタープロファイル TTL 60 s、レコード TTL 5 m、相互作用カウント TTL 30 s、投稿メタデータ TTL 5 m) - 通知設定のサーバー側強制 実装された修正: - JWT 検証における古い署名鍵の処理 - JSON のサニタイゼーションで null バイト/制御文字を除去 - アクターメモリキャッシュ内の protobuf タイムスタンプバグへの対策 Blacksky は **コミュニティ投稿サポート** をカスタムレキシコン namespace(`community.blacksky.feed.*`)と専用 `community_post` テーブル、データプレーン/API 層でのメンバーシップゲーティングを通じて追加しています。これは混在した投稿スレッド(`getPostThreadV2`)とも統合されます。 全体アーキテクチャフロー: Bluesky Relay → rsky‑wintermute(フィーホーズコンシューマ/バックファラー/ラベルインデクサ) → PostgreSQL 17 → bsky‑dataplane(gRPC) → オプションの Redis キャッシュ → bsky‑appview(HTTP) → リバースプロキシ、Palomar が OpenSearch 検索機能を提供 バックフィル性能: ライブインデクシングは約1 k イベント/秒。42 M ユーザーと 18.5 B レコードのフルバックフィルは10 k レコード/秒で 2–4 週間、部分的なバックフィルは数時間〜数日で完了 ブートストラップ課題への対策: - PostgreSQL COPY による JSON 腐敗 - null バイト処理 - タイムスタンプ精度の強制 - 通知テーブルの肥大化緩和 - 投稿埋め込みテーブルの人口化 - ラベル否定順序 - Fjall キュー毒性解決 - TLS プロバイダ初期化 - アカウント移行後の署名鍵回転 **フルネットワーク AppView のリソース要件:** ≥ 16 CPU コア(推奨 48+)、≥ 64 GB RAM(256 GB 推奨)、10 TB NVMe ストレージ(28 TB RAID 推奨)、同一マシンまたは低遅延での PostgreSQL、継続的ネットワーク 100 Mbps(1 Gbps+)以上の取り込み帯域 リポジトリは MIT/Apache 2.0 のデュアルライセンスです。アップストリーム同期手順は `git remote add upstream https://github.com/bluesky-social/atproto.git` で提供されています。

2026/03/09 4:58

「エージェント時代にリテラトープログラミングを見直すべきです。」

## Japanese Translation: > 本稿は、コードと説明文を組み合わせたリテラトープログラミングが、AI エージェント(例:Claude や Kimi)が Org‑Mode ファイルを単一の真実源として扱う場合に実用化できることを主張しています。 > > Org の構文を解析することで、これらのエージェントはランブックを生成し、埋め込みコードブロックを実行し、Jupyter ノートブックのように結果を保存し、プローズとコードを同期して自動的に更新できるため、ナラティブと実行可能なスクリプトを分離する手作業「タンギング」ステップが排除されます。 > > 著者は、Org Mode を設定管理に個人的に使用した例でこれを示しています:エディタ内で直接コマンドを書き込み、それらを実行し、メモを自動的に取得します。 > > コードとプローズの2つの並列文書を維持することは採用への一般的な障壁ですが、AI 主導のワークフローは `AGENTS.md` ファイルに記載された指示(実行前のタンギング、常にステップを説明するプローズ、両側を同期させる)に従うことでそのオーバーヘッドを排除します。 > > このアプローチはワークフローを合理化し、コードベースを複数の読みやすいフォーマットへエクスポートしやすくし、「コードを書く」から「コードを読む」へのシフトを促進します。また、大規模プロジェクトにおける Org‑Mode の Emacs 統合の限界を浮き彫りにし、リテラトープログラミングの普及を広げるために Markdown などの類似フォーマットを推奨することも示唆しています。

**Z80 Sans – フォントで実装したディスアセンブラ (2024)** | そっか~ニュース