そうそう、問題は教育方法が「計算機」とOSの部分をどうつなげるかを明確にしてないことだよね。子供の頃に俺もこれに悩んだ。足し算がどうやって画面に何かを描くことにつながるの？もちろん、直接は関係ないんだけど、ハードウェアやOSに特有の情報が必要なんだよね。

とても興味深いね、ソースを共有してくれる？

俺はWebAssembly WAT（リスプに文法的に似た中間表現）を使って、リスプのASTをほぼそのままWAT IRにマッピングして、そこからバイトコードを出力するってことをやったんだ。結構楽しかったよ。

昔、Java版のタイガー言語を扱ってたときに似たようなアプローチをしたよ。コンパイラのIRをアセンブリマクロにモデル化して、古典的なUNIXコンパイラのビルドパイプラインに従ったんだ。だから、世界で最もパフォーマンスの良いコンパイラではなかったけど、最終的におもちゃのコンパイラが実際の実行可能ファイルを生成するのを楽しめたんだ。

まあ、そんなに難しいわけじゃないんだけど、一部の命令セットのエンコーディングが本当にクソで、特に32ビットと64ビットのx86がその代表例だし、Thumb-2もそれに続く。あと、既存のコードを動的にパッチする場合、現代のOS（特に「ハードニング」パッチ）によって、独自の互換性のない方法で面倒になることもあるし（libffiの大半を参照）、現代のCPUは自己修正コード周りでバグが多いからね。それ以外は、どこにでも行くためには、面倒だけど単純な作業がかなり必要だよ。

うん、それは役に立たないね。俺には、何か複雑なテトリスゲームみたいに見える。プログラムをレジスタや命令のピースで表現できるかもしれないけど、今あるツールはすごく簡潔で、テキストベースなんだよね。

個人的には、アセンブリの種類によると思う。学ぶのに最適なISAはおそらくMotorola 68000で、その次がいくつかの8ビットCPU（6502、6809、Z80）かな。ARM1も多分いいけど、扱ったことはないんだ。x86アセンブリは見た目が悪いと思ってたし（IntelでもAT&Tでも関係なく）。> 現代のツールを使うと大きなプログラムを書くのはすぐに面倒になるけど、アセンブリコーディングは意外と生産的になれるよ。例えば、8ビットのホームコンピュータ用にVSCodeの拡張機能を書いたことがあって、ちょっとしたデモも作ったんだけど、それが昔のデバイス上のアセンブラや、数字で機械語を打ち込むのと比べてずっと生産的に感じた。

いいマクロアセンブラがあれば、Cよりちょっとだけ難しいくらいだよ。最初に覚えることが多いけど（呼び出し規約やレジスタの使い方とか）。最初に教えるつもりはないけど、他の言語の基本を知った後に、実際にどう動くのかを見るのは楽しいかもね。

ASMを初心者に最初の言語として教える最大の問題は、非常に面倒でエラーが起きやすく、細部に敏感だってことだよ。それに、構造がなくて、将来学ぶ言語とは全く異なる制御フローのプリミティブを使うから、複雑なプログラムを学ぶ準備ができていないことになる。だから、ifやwhile、（ローカル）変数、スコープ、型、さらには本物の関数呼び出しもない言語を教える意味はあるのかな？コンピュータがどう機能するかを理解するための良い練習にはなるし、教育において明確な役割があるのは認めるけど、最初に学ぶ言語としては最悪だと思う。

最初はZ-80アセンブリから始めて、その後BASIC、6502アセンブリ、そしてCやPerlみたいな高級言語に進んだんだ。アセンブリのおかげで、内部で何が起こっているかの基礎ができたと思う。アセンブリを他の言語と同じ「言語」と呼ぶかは微妙だけどね。命令はあるけど、文はないし、文法も本当にないから。もし一般向けのプログラミングコースを教えるなら、まずはBASICを少し触れて、変数やループみたいな広い概念を紹介してから、アセンブリを少し見せて「これがその時に何が起こっているかだよ」って感じで進めるかな。それからCに進んで、デバッグ用に生成されるアセンブリを見た時に、レジスタや分岐みたいな概念には少し慣れているだろうし。だから、僕がやった順番とはちょっと違うけど、似たような感じだね。

初心者にはすぐにポジティブなフィードバックが必要だよね。アセンブリ言語ではそれが無理なんだ。

「ASMが最初の段階の教育言語として合理的だと人々を説得しようとしたことがある。」エンジニアリングハードウェアを準備している人を教えているのでなければ、ASMはこの目的には絶対に間違った言語だと思う。最初の理由は、プログラミングは問題解決に関するものであって、特定のアーキテクチャの詳細をいじることではないから。ASMは問題領域の言語で解決策を明確に表現するのが得意じゃない。領域の言語でプログラミングする代わりに、実装の詳細であるビットをひっくり返すことに忙しくなっちゃう。これはハードウェアとインターフェースを取るための言語なんだ。もっと厄介な結果は、ASMを教えることでハードウェアが神格化されて、コンピュータサイエンスやプログラミングが計算デバイスに関するものであるという考えが強化されること。実際にはそうじゃない。計算デバイスは主題に関しては完全に補助的なものだ。実用的には絶対に必要だけど、プログラミングが本質的に関わっているものではない。天文学者が望遠鏡をうまく操作できるのは良いけど、彼は望遠鏡を研究しているわけじゃない。望遠鏡のエンジニアがそれをやるんだ。

昔、最初にBASICを学んで、その後Cを学ぼうとしたけどポインタが理解できなくて、ASMを学んだらポインタが明確になって、またCに戻ったんだ。Cを使ったりハードウェアに関わることをするなら、ASMを学ぶのは本当に役立つと思うよ。マシンがどう動いてるかを理解するためにはね。

彼らに物事をやらせるのは難しくないが、基本的なレベルで考えられるスケールを超えるタスクになると難しさが出てくる。確かに、難しいタスクに取り組まなくても知的なメリットは得られるよ。コンピュータが何かをしっかり理解したら、SICPのアイデアを吸収できるようになる。

ほとんどのCSプログラムでは、学生は早いうちにアセンブリを学ぶと思うよ。最初の言語ではないかもしれないけど、ほとんどのアーキテクチャのコースでは必須の第二言語としてね。

アセンブリ言語の入門コースでTAをやってたんだけど、そのおかげでアセンブリに苦しむ学生たちと一対一で向き合って、彼らがクラスを通過するための障害を乗り越える手助けをしてたんだ。アセンブリ言語は、最初のプログラミング言語としては合理的じゃないよ。プログラミング教育には不向きな要素がたくさんあるから。特に、アセンブリは構造がない。変数なんて存在しないし、関数もない。慣習でそれっぽくすることはできるけど、間違いを犯すと（プログラミング入門の学生は必ず間違える）、何かが間違ってるって教えてくれるものがないから、ただ間違った結果が出るだけなんだ。

知識を維持するには、実際にプロダクションでやる必要があると思う。趣味でやるだけだと、ほとんどの人はある時点で諦めちゃうんだよね。無駄に頭を壁に打ち付ける理由がないから。解決すべき本当の問題が必要だよ。

僕も同じことをやったよ、48kのスペクトラムで、1年か2年後にね。関数の間にNOPを入れるのも忘れずに、変更があった時に相対ジャンプ命令を再計算しなくて済むようにしたんだ。

僕が理解できたきっかけになったことを試してみるといいよ、x86が主流になった後でもね。Logisim（または新しいDigitalみたいな）で動いているCPUを見せて、プログラムをROMに入れるとどうなるか、配線が光ったりゲートが切り替わったりデータラインがアクティブになったりする様子を見せるんだ。

Steamで「Human Resource Machine」を買ってあげるか、（できればDRMなしの）Good Old Gamesで手に入れてあげて。これは昔の8ビットCPUで機械語を書くのがどんな感じだったかをゲーム化したものなんだ。HRMのパズルチャレンジは、単一のアキュムレータと非常にシンプルな命令という自然な制約から生まれているから、本物の体験だよ。Zachtronicsのゲームみたいに不自然に制約を加えたものではないから、良いけど学習ツールとしてはあまりお勧めしないかな。

アセンブリ言語を学ぶことを推奨している人のほとんどは、実際のプロダクション環境で使ったことがない… 大多数のプログラマーにとって、アセンブリは全くメリットがない。よくわからないな。アセンブリがプロダクション環境で役立つか楽しい必要があるの？学ぶことが役立つためには。大学でいくつかのアセンブリのバリエーションを教わったけど、マシンが実際に何をしているのかを理解するのにはかなり役立ったよ。Cよりもね。抽象化は結局、何かに根ざさないといけないから。

実際にはプロダクションで使ったことはないけど、学ぶことで絶対にメリットがあったよ。アセンブリを学ぶまでポインタが理解できなかったからね。

一度、サイドギグで、8ビットのアキュムレータしかないプロセッサで16ビットの長除算ルーチンを書く必要があった。その時点で、もう二度とアセンブリプログラムを書くことはないと決めた。こういう仕事は楽しそうだな！明確な要件がある技術的な挑戦ができる。数独パズルを解くのが好きな人もいれば、プログラミングパズルを解くのが好きな人もいる。俺は「大多数のプログラマー」じゃないってことかな。

6502やZ80のような8ビットのホームコンピュータCPUでは、Cのような高級プログラミング言語は選択肢にならなかった。パフォーマンスを無駄にしすぎるから（手書きのアセンブリに比べてBASICは簡単に100倍遅かったし）。Forthはパフォーマンス的にはかなり良かったけど、良いマクロアセンブラの上くらいだね。そして8ビットの後、アミーガでのアセンブリコーディングは純粋な楽しみだったよ。大きなプログラムでも、素晴らしい68k ISAのおかげで、アセンブリコーディングが便利になるようにアミーガのハードウェアとOSが書かれていたからね（Cは68kではずっと良かったけど、真剣なプログラムのほとんどはCとアセンブリのミックスを使ってた）。それに、今アセンブリコードを書くことはそれほど重要じゃないけど、コンパイラの出力を見て、なぜコンパイラが俺の高級コードを台無しにしたのかを理解するためには、アセンブリコードを読むことは絶対に重要だよ。

ほとんどの人はプロダクションで使うチャンスがないよね。そこから憧れが生まれたんだと思う。現代のアジャイルなウェブやデータ開発シーンに疲れ果てて、利害関係者が数時間ごとにプレッシャーをかけてくることなく、特定の分野に深く掘り下げたいと思ってる。アセンブリプログラミングはそれを便利に提供してくれる。俺は、強制的でも自発的でも、システムの理解を深め、低レベルのコードを脳内で実行する能力を大幅に向上させるための試練だと考えてる。苦痛なのか？確かにそうだけど、これは技術的なスキルをもたらす苦痛だよ。ほとんどの人は、ちゃんと苦しむ特権がない。君は、不完全なドキュメントや非常に低レベルのコードで頭を壁に打ちつける苦しみを選ぶ？それとも、不完全なドキュメントや層層の抽象化、毎日変わる利害関係者の要求に苦しむことを選ぶ？俺にとっては簡単な選択だと思う。アセンブリ言語やCの仕事があれば、今の給料の半分でやるよ。

C言語を発見する前に、アセンブラプログラミングをたくさんやってたんだ。だから、Cは1時間くらいで覚えられたよ。アセンブラを知らないと、Cで何が高コストな操作か、どれが良いコードを生成するかの視点がちょっと欠けちゃうんだよね。例えば、プログラムのデバッグには生成されたアセンブラを見なきゃいけないこともある。最近、わざとヌルポインタをデリファレンスしても例外が発生しない理由を考えてたんだけど、アセンブラを見たら、そのための命令が生成されてなかった。ヌルポインタのデリファレンスは未定義の動作だから、コンパイラはそのための命令を生成する必要がなかったんだ。

アセンブリを書くこと自体は、ほとんどの開発者にはあまりメリットがないと思う。でも、アセンブリを読んで理解することは一般的に役立つよ。完全なソースコードがないバイナリやクラッシュダンプのデバッグができるし、Windowsに付属するDLLやサードパーティのDLLも扱える。コンパイラ（従来のものやJIT）によってソースコードがどう変わったかを理解するのも役立つし、パフォーマンス最適化をする際には特に重要だよね。

アセンブラで書くのが本当に必要なわけじゃないこともあるよね。例えば、AArch64で定数をレジスタにロードする時とか。これをやるための命令はちょっと変わってて、正しい組み合わせで値をロードしたかどうか見極めるのが難しいんだ。だから、コンパイラにやらせるのが一番だよ（それかgodbolt.orgを使って正しいミックスを得るとか）。浮動小数点定数も同じ。AArch64のコードジェネレータでこのコードシーケンスを正しく設定できたら、もう二度と考えなくて済むからね！

現代のコンパイラは、手でアセンブリを書くよりも最適化されたコードを生成するのが得意だって意見も聞いたことがある。どれだけ真実かはわからないけど、現代のCPUの理解しがたい複雑さを考えると、信じられそうだよね。

私はアセンブリからキャリアをスタートさせて、時間が経つにつれて減ってきた。ゲーム開発の仕事の終わり頃には、まだたくさんのアセンブリを読んでたけど、書くことはなくなった（代わりにインライン関数を使ってた）。書くのは確実に遅かったけど、Cではできない、または難しいことがいくつかあったんだ。- テールコールの保証 - メモリに触れずに複数の値を返す - スタックポインタを一般的なポインタとしてメモリに書き込むために使う - コルーチンをサポートするためにスタックポインタを変更する - 自分たちのレジスタ/呼び出し規約を使う（例えば、すべてのルーチンで使えるようにレジスタを確保する） - よく使うルーチンや高速なロングジャンプのためにスタックを解体してレジスタのセットアップを減らす - VMの「ジャンプテーブル」を使って、ジャンプ先を知るための間接参照を必要としない