Pythonがハードウェアで動く？プロセッサを作ってみた！
引用元：https://news.ycombinator.com/item?id=43820228
このプロジェクトは超クールだけど、記事の主張は盛りすぎだと思うな。”PyXLはPythonを直接動かす特別なプロセッサで、普通のPythonコードをそのままシリコンで動かすんだ”って言ってるけど、CPythonでコンパイルして専用ISAのバイナリにするって書いてあるじゃん？それって他のCPUと同じで、コンパイルされたやつを動かしてるだけじゃん？「Pythonをサポートするために作られた特殊なプロセッサ」って言うのが正直だと思うな。
プロジェクト自体とは関係ないんだけどさ、ハードウェアがCPythonのバイトコードで動いてるなら、Pythonを直接動かすっていう点ではこれで十分なんじゃない？だって普通のpython3だって、まず＊。pycファイルにしてから動かすじゃん。それってPythonを直接動かしてるって言わないの？…
そうだね、もしpycコードを直接動かしてるなら「Pythonを動かしてる」って言っていいと思う。でもそうじゃないみたいで、pycをさらにマシンコードに変換するって。だから親コメントみたいに、ちょっと紛らわしいなって俺も思うよ。
でも、そのネイティブコードがpycにめちゃくちゃ近いなら、まあ納得できるかもね。起動時にpycをマシンコードに変えるやつは書けるのかな？もし無理ならなんで？
まあね、CPythonじゃなくて、CPythonバイトコードをアセンブラにしたやつを動かしてるわけだ。専用のアセンブラだけどね。とにかく、プロジェクト自体はめちゃくちゃクールだし、すごく役に立つよ（特定の場面ではね）。ただタイトルがちょっと分かりにくいだけかな。
コンパイラ理論的にはそうかもね。でも「Pythonを直接動かす」って言ってるのは、仮想マシンやインタプリタがないって意味だよ。プロセッサはPython ByteCodeからできたロジックをハードウェアに直接マッピングして動かしてるんだ。普通のシステムより「直接的」って言いたかったんだ。ソフトで解釈じゃなくて、ハードでネイティブに動くんだよって違いを伝えたくて。
AoTのPythonをx86にするコンパイラを使ったら、x86プロセッサが「Pythonを直接動かす」って言ってるような感じになるんじゃない？
ちょっと探してみたら、Raspberryも似たようなこと言ってたよ…
「組み込みハードウェアで直接動作」
https：／／www。raspberrypi。com／documentation／microcontrollers／m。．．．
なんでこういう言い方するのかよく分かんないな…
Micropythonはハードウェアで直接動くよ、それはそう。OSなしのベアメタルバイナリだからね。でもそれは、渡されたPythonコードを「直接」動かすっていう今回の話とは違うんだよ。
うーん、Raspianでpython動かすと、ピンをいじるのがせいぜい数KHzくらいだけど、このプロジェクトなら2MHzもいけるんだって。それに予測可能性も高いって言ってるから、時間のブレも少ないはず。これはリアルタイムなことやるにはめっちゃ大事なんだよね。
え？MicroPythonってまさにそれじゃん。PythonのソースコードそのものをコピーしてPicoで動くんだよ。
最初に思ったのは「あれ？コンパイルされてるコードじゃん、直接じゃないじゃん」ってこと。記事の主張はちょっと盛りすぎかもね。まあそれでもすごいけどさ。新しいPythonのバージョンが出るたびにアップデート大変そうって思った。あと、ASTを直接ハードウェアでやるみたいなのってあるのかな？Lispマシンとか近いのかも。リアルタイムで変わるFPGAとかいるのかな？
PyXLはPythonの細かい構文変更に縛られないように作られてるよ。PythonソースをByteCodeにして、そこからハードウェア向け命令にするんだ。ByteCode使うから言語の変更には強いんだって。ハードウェアは固定で、将来のアップデートはツールチェーン側でやるんだ。シリコンいじらなくてもPythonと進化できる仕組みだよ。
それってnuitkaがやってることと似てるね。でもnuitkaの結果だとリアルタイムなPythonプログラムは無理だし、今回みたいにハードウェアに直接アクセスできないんだよね。
どんなコードが動かせるか制限はある？（メモリとかOS以外で）設計プロセスについてもっと知りたいな。Pythonとか動的言語のバイトコード向けにカスタムプロセッサ作るってアイデア、すごいと思うし面白いね。なんでこれやろうと思ったのか、どうやって実装したのか（大まかでいいから）教えて欲しいな。
興味持ってくれてありがとう！メモリとかOS以外にも制限はあるよ。
今はPyXLはPythonのサブセットだけ。まだ実装してないCPython機能も多いけど、まずはハードウェアでPython動くって見せるのが目的。
ユースケース見ながら進めたいんだ。あと重いruntime reflection、 dynamic loadingとかは多分サポートしないかな。組み込みとかリアルタイム向けだからね。
設計プロセスはもっと詳しく話したいんだけど、今PyConの準備で忙しくて。
終わったらウェブサイトで詳細ブログ書く予定だよ。
ターゲットの機能セットは”real” PythonじゃなくてRPythonを狙うのはどうかな？PyPyがやってきたみたいに、Pythonの核となる部分と使いやすくしてる部分を分ける仕事、あれが活用できると思うよ。
＞ I’d prefer to move forward based on clear use cases
例えばstruct moduleみたいなやつってどうするの？あれCで書かれてるのが大変だよね。そういうstdlib moduleってpure pythonで全部書き直さなきゃダメなの？
自分の前のコメント（600）でも言ったけど、pypyはもうこの手の仕事は全部やってるよ。CPythonのstruct moduleはC implementationをimportしてるだけだけど、PyPyのはPython（ーish）implementationで、独自のrlibとかpypy.interpreter spaces使ってるんだ。Python stdlibはめちゃ広いし、もちろん常に変わってるから大変だよね。
へえ、すごいね！うん、ここでpypyの成果に乗っかるのが一番賢明だろうね。投稿者さんがディクショナリとかリストみたいなものをどう扱うのか見るのも面白そう。
バイトコードをハードで動かすのはARMのJazelleとかでも試されたけど、今は大変。複雑な命令や型情報不足でハードに合わないからソフト処理が増えるし、型追跡も必要。あと、Pythonとかのバイトコードは最適化がほぼされてない。これはデバッグやJITとの兼ね合いでそうしてるんだけど、結果として最適化されてないコードをハードで動かすことになる。これがキツくて、既存のJIT+x86/ARMに負けるんだよ。
Lisp Machinesが消えた理由って、これ（上のコメントの話）と同じだって理解してるよ。SICPのビデオでそう言ってた気がする。1986年とかには、ASMにコンパイルする方がずっと良いってのは明らかだったらしいし。
JVMのバイトコードを直接実行できるチップもいくつかあったよ。なんで普及しなかったかはよく知らないけど、ホットスポットをネイティブコードにJITコンパイルする方が、一般的にパフォーマンスが良いからじゃないかと思う。
いや、違う方向でちゃんと普及したんだよ。Java Cardみたいにね。世界のほとんどの大人、SIM cardの中にJava対応のプロセッサ持ってるんじゃないかな。少なくともエミュレーター（eSIMの場合だけど）。JavaCardデバイスで使われてるCPU archの例としては、ARM926EJ-Sがあって、これはJava byte codeを実行できると思うよ。
Forth CPU（SystemVerilogで書かれたもの）の動画はこちらだよ：
JVMは分かる気がするんだけど、LISP Machinesについてはもっと詳しく知らない？ISAは言語に特化してたの？それともx86向けのコンパイラも結局同じことしてるの？全体的に、実際の結果としてはx86が民主主義みたいだと思うんだ。いつも効率が良いわけじゃないけど、他の要因で一番良い選択肢になってるっていう。
LISP Machinesは言語に特化して最適化されたISAを使ってたんだよ。当時は、普通のハードウェアでLISPのコンパイラをうまく作る方法がまだよく知られてなかったんだ。
あと、世界のコンピューターの圧倒的大多数はx86じゃないよ。
待って。LISPのコンパイラは、当時でもかなり良いのを作る方法が知られてたし、実際悪くなかったよ。一部のLISP特有の部分（数体系とか、bignumへのオーバーフロー、有理数とか）は問題があったけど（カスタムHWがない今でもそう）、でもそういう部分は汎用的な用途ではそこまで重要じゃなかったんだ。
LISP ISAの時代って、結局そんなに長くなかったしね。
1970年代後半の普通のハード向けLISPコンパイラ（MACLISPとか）は、数値計算以外は性能がイマイチだったんだ。Gabrielの本のTakベンチマークとか見ても遅い。Generational GCみたいな技術が普及するまでは、普通のハードで高速なLISPコンパイラは難しかった。だからLISPマシンが生まれたんだよ。今のSBCLやChez Schemeはすごい進化してて、カスタムHWなしでもC並みに速いけどね。
RISCプロセッサが出てきた頃（RISCが普及し始めたのと同じ理由だよ）は、ASMにコンパイルする方が良かったんだ。
俺はPythonプログラムをVMとかインタプリタなしで直接動かすハードウェアプロセッサを作ったんだぜ。
初期のベンチマークだけど、GPIOの往復は480nsで、MicroPythonのPyboard（低クロックなのに）より30倍速いんだ。
デモはここ：https://runpyxl.com/gpio
もっとコメントを表示（1）
もっと早い時期（2012年）にFPGAでPythonバイトコードインタプリタをやろうとした試みもあるんだよ：https://pycpu.wordpress.com/”FPGAでPythonのすごく小さなサブセットを動かすのはpyCPUで可能だよ。
The Python Hardware Processsor (pyCPU)はMyhdlを使ったハードウェアCPUの実装なんだ。CPUはPythonバイトコードにすごく似たものを直接実行できる（命令セットはすごく限られてるけどね）。だから、CPUのプログラムコードはPythonで直接書けるんだ（Pythonのすごく限られた部分だけど）…”
これはすごく、すごくクールだね。素晴らしい仕事だよ。カスタムハードウェアを作る代わりに、Pythonっぽい構文で型安全な言語を作ってネイティブにコンパイルする方が、最終的な機能セットが広がるのかどうか興味あるな。バックグラウンドのガベージコレクションは言うは易く行うは難しだけど、驚くほど難しいことをもうやった人と話してるからね…
＞カスタムハードウェアを作る代わりに、Pythonっぽい構文で型安全な言語を作ってネイティブにコンパイルする方が、最終的な機能セットが広がるのかどうか興味あるな。
それって、ほとんどNim（https://nim-lang.org/）を求めてるみたいだね。マイクロコントローラーのプログラミングで使ってるプロジェクトもいくつかあるよ、Cにコンパイルされるからね（ESP32向けとか、最後に見た感じだと）。
なんでPythonを”コンパイル”するのが普通じゃないの？インタプリタが高速な反復とかクロス互換性に優れてるのは分かるんだけどさ。でも、なんでPython界隈では、本番環境に”ソース”ファイルをドカッと置いて、コンパイルのメリットを全部捨てちゃうのが一般的なやり方になってるんだろう？
Pythonがコンパイルされない主な理由は、ライブラリに型アノテーションがないことだよ。型が動的でmonkey patchingがあるから、コンパイラは最適化が難しく、実行時に”再コンパイル”が必要になるんだ。”a.b”みたいな操作も、型が分かんないとどう呼ばれるか特定できない。JITコンパイラなら少しは最適化できるかもね。
型情報も大事だけど、Pythonの遅延バインディングも動的な性質の基本だよ。変数や関数は実行時に決まることが多くて、動的に変更されるんだ。だから型アノテーションがあっても、実行中の変更に対応する必要があって、静的コンパイルが難しいんだ。だからPyXLは効率的な動的実行に注力してるんだ。
Smalltalk、Self、LispのJITで解決されてる問題だよ。これらはJIT技術の源流にあって、その一部はHotspotやV8に受け継がれてるんだ。
Pythonも3.13からJITが使えるようになったよ。
まあね、自分でコンパイルしないといけないし、結構基本的なことしかできないよ。まだ始まったばかりって感じ。PyPyとかGraalPyの方が面白いことやってるんだけど、言語研究界隈の外だとあんまり知られてないのが現状かな。
”解決済み（Solved）”ってよりは”対処済み（Addressed）”とか”緩和済み（mitigated）”が近いんじゃないかな。”解決”ではないね。”痛みを軽減した”とか”部屋から悲鳴を上げて逃げ出さなくて済むくらいには痛みが減った”って感じ。
CPythonでみんながやってることと比べたら、それは”解決済み”って言えるよ。CPythonで完全なグラフィックスワークステーションを作るなんて程遠い話だし、JITが完璧じゃなくてもね。そういう試みもいくつかあるけど、コミュニティのほとんどはC拡張書く方を選ぶのが現状だよ。
”シングルユーザーグラフィックスワークステーション”って今どき目標なのかな？昔のワークステーション時代なら良かったけど。昔、Self, Java, Python（PyPy）でJITやGC使ってたけど最高だったね。JITはネイティブに”十分近い”性能で、高レベル抽象化を使えるようにするのが価値だった。これは成功だけど、AOTと比べるとAOTが勝つことが多い。”解決済み”なら性能で言語を変える必要はないはず。でもJuliaやRustが性能のために盛り上がってるのを見ると、JITはギャップを縮めたけど解消はしてないって感じるな。
”シングルユーザーグラフィカルワークステーション”は最高の目標じゃないかもだけど、達成できないマイルストーンとしては良いね。知る限り、JVMバイトコードからネイティブへのAOTコンパイラでHotSpotやGraal（JIT）に匹敵するのはない。JVMはPythonやJSより動的じゃないからね。Jython＋HotSpotも遅い。でもLuaJITはLuaがPythonより動的だけど、AOTなCやHotSpotに匹敵するみたいだよ。
コミュニティのユーザーがインタープリタの遅さを補うために、いつもC拡張書いてるわけじゃないレベルでは解決済みだよ。マイクロベンチマークでAOTがJITに勝っても、JITキャッシュとかPGOの実行間データ共有を考慮すると、ほとんどのビジネスアプリでは大した意味ないね。AOTが必要なユースケースは常にあるけど、デプロイ制約が理由が多い。ほとんどの一般的な開発者はAOTツールのPGOすらちゃんと使えないよ。てか今、Electronアプリいくつ動かしてる？
＞CPythonで完全なシングルユーザーグラフィックスワークステーションを作るなんて程遠い…これについてだけど、数年前にSnakewareっていうPythonユーザー空間を含むLinuxディストリビューションを作ろうとした試みがあったらしいよ。でもそのプロジェクトはそれ以来活動停止してるみたい。GitHubに情報があるよ。
Pythonで書かれたデスクトップシステムが十分なパフォーマンスを持ってるって情報、全然見つけられないな。
SugarはPythonで作られてるよ。GitHubにある。
＞一番の理由は、ほとんどのPythonライブラリに型アノテーションがないことだと思う（標準ライブラリ含む）。型アノテーションがあれば、Mypycを使ってPythonをコンパイルしてパフォーマンスを改善することはもう可能だよ。例えばこのブログ記事見てみて。
Pythonは全部コンパイルを避けてるわけじゃないよ。バイトコードにはコンパイルされるけど、ネイティブコードじゃないんだ。JavaとかC#がバイトコードにコンパイルされるのと似てるかな。Javaとかは実行時（最近はコンパイル時も）にネイティブコードにするけど、Pythonはインタープリターで動くんだ。そうしない理由は、エンジニアリソース不足，シンプルにしたいって思い，あとCコードがPythonオブジェクトを操作するための後方互換性が必要だからだよ。
「Pythonをコンパイルする」って，もしインタープリターの動きをCPU命令にするだけなら，あんまり速くならないよ。遅いのはインタープリターじゃなくて，内部で動くCコードの処理だから。
最適化目的のコンパイルならPyPyがあるけど，あれは速くなる分，別のトレードオフがあるんだ。「タダ」で速くなるわけじゃないんだよね。
動的言語の大きなコストはメモリアクセスだよ。Pythonだと，値の型とかサイズとかを事前に知るのが難しいから，Cとかみたいにレジスタに入れられないんだ。
Cython，PyPyみたいなツールや，numpyみたいな最適化ライブラリで速くできるけど，Pythonの柔軟さのために多くの処理でメモリ上の動的な構造にアクセスする必要があるんだ。これはレジスタアクセスよりずっと遅い。
ほとんどの場合，これらの助けがあれば十分速いけど，それが足りない人はRustとかJuliaとかに移る傾向があるね。メモリアクセスのコストなしにPythonをやるのは難しいんだ。
Pythonが遅いのは，値を調べて型を確認する作業が多いから。Cでx＋yをコンパイルするのと違って，Pythonだとコンパイル時に型が分からないから，どの「add」を使うかとか実行時に決めなきゃいけない。だからコンパイラにインタープリターが必要になるんだ。
静的型付けを入れる手もあるけど，それだと言語の便利さが減る。だからMojoみたいなプロジェクトは，Pythonに見えるけど全く別の速い言語を作ろうとしてるんだ。
オーバーロードされた演算子のためにインタープリター全部が必要ってわけじゃないよ。CPythonも似たようなことやってるし，Golangみたいにvtableで作ってるんだ。
静的型付けがなくても，オーバーロード演算子で decent な性能は出せるよ。Ur-Schemeの経験だと，簡単な整数予測と実行時型チェックを入れるだけで，CPythonより数倍速くなったんだ。
知ってる限り，メリットは特にないね。もしかしたら，インタープリターがバイトコードを生成する必要がない分，起動がちょっとだけ速くなるかもってくらいかな。
エンドユーザーに配布するクローズドソースのソフトで，リバースエンジニアリングとか改変を（ちょっとだけ）難しくするためにやってる人は見たことあるよ。
Nuitkaを見てみて：https://nuitka.net/
Cython，Nuitka，PyPyのJITみたいに，Pythonの一部をコンパイルしたり，実行を追跡したりして速くしようって試みはあったよ。でも，知ってる限り，標準の動的なモデルを完全に置き換えるものはないね。
Pythonのコンパイルはバイトコードを出すことなんだ。そのバイトコードを配布することはできるけど，Pythonはすごく動的だから，何が何と結びつくか実行時まで分からないんだ。型アノテーションも静的チェッカー用で，コンパイルには使われないことが多い。
最適化なしじゃ，コンパイルはバイトコードより先に進めないんだ。昔，*.pycとlibpythonをまとめる「freeze」っていうプログラムがあったね。
” なぜPythonの「コンパイル」は一般的じゃないの？
Python言語全体を扱えるAOTコンパイラはどこにあるの？
一般的じゃないのは，そもそもそれが選択肢にないからだよ。心配してる人たちは，プログラムの一部をコンパイルできるツールを使うか，別の言語を使ってるんだ。
AFAIK、”eval()” 使っちゃうとさ、コンパイラ全体が必要になるから、結局インタープリタごと配布するのと変わらないんだよね。
Nim とコンパイルした Python 比べるのはマジ失礼．バイナリ小さいし、速いし、ちゃんとしたメタプログラミングもできるし、ちゃんとした型安全だし、”hello world” 程度で interpreter なんていらないんだぜ．
もっとコメントを表示（2）
うん、同意．分かりやすく言っただけだよ．文法似てるから Python の開発者が高性能なものに移行しやすいって点はあるけど、基本的には全く別のもの．マジで言いたいのは、”型付き Python” なんてのはやり方間違ってるってこと．あれはそういう風に作られてないし、多分これからもそうはならない．最初から強い型付けを考えて作られたツールを使うべき．Nim はそれにピッタリだよ．
＊ プロセッサ設計に使った HDL は？
＊ そのプロセッサのアセンブリ言語教えて？
＊ ARM／x86／RISCV みたいな既存プロセッサ向けじゃなくて、なんで自作プロセッサ向けに Python バイトコードコンパイラ作ったの？
これなんで？
質問ありがとう．HDL は Verilog．アセンブリは PySM （あんまり独創的な名前じゃないけどね）っていうカスタム命令セットを実行するよ．CPython Bytecode にヒントを得てて、スタックベースで動的型付けなんだけど、ハードウェアのパイプライン処理効率化のために合理化してる．
今はフル ISA はまだ公開してないけど、全体像だけ説明するとね．スタック操作、計算、比較、分岐、関数呼び出し、メモリ操作なんかの命令がある．
なんで ARM／X86 とか使わなかったかというとね…
既存 CPU は C／C＋＋ みたいな静的でレジスタベースのコンパイル言語向けに最適化されてるから、Python の動的な性質、つまりスタックベース実行、実行時型処理、動的ディスパッチなんかは従来の CPU とめっちゃ相性が悪くてさ、たくさんの無駄（インタープリタのオーバーヘッド、動的型付けのペナルティ、参照カウント、キャッシュの局所性とか）が発生しちゃうんだよ．
うわー、これマジ面白いね．ちょっと脱線した質問なんだけど （低レベルハードウェア詳しくないから変な質問だったらごめんね）：このアーキテクチャって投機的実行とかサポートしてるの？ もしそうなら、それに伴う脆弱性とか心配してたり対策してたりする？
ありがとうー．大丈夫、それマジいい質問だよ！
今んとこ PyXL は投機的実行なしで、完全インオーダー実行にしてる．理由はいくつかあってね．
まず、リアルタイムとか組み込みシステムだと決定性がマジ重要だから、投機的実行避けてタイミング予測可能にして、副作用の脆弱性とかなくしたいんだ．
あと、PyXL はまだ初期段階だから、性能のために複雑な最適化じゃなくて、構造的に分かりやすくて効率的なアーキテクチャ作るのに集中してるんだ．将来もしマジで必要になったら、予測可能性とかシンプルさを壊さないように、めっちゃ注意して一部の予測を取り入れるかもね．
スタック操作とか計算命令って言ってたけど、他の Python データ型（floatとかstring、tupleとか）ももう実装してるの？ もししてたら、1 ＋ 1．0 みたいに違う型同士の計算はどう処理するの？ スタックに乗ってる型見てディスパッチテーブルみたいなのある感じ？
Python 言語自体はスタックベースじゃないよ、CPython のバイトコードがスタックベースなだけ．レジスタベースの命令セットの上でも普通に実装できるし．まあ、他のコンパイルを難しくするっていう点については言いたいこと分かるけどね．
これってさ、キミの’arch’（ごめん、正確な用語かわかんないんだけど）もしかしてtoolchainがassembly languageに解釈できれば、RubyとかJSも動かせるんじゃない?
良い質問だねー、100％は確信ないな.
RubyとかJSのinternalsに詳しいわけじゃないし、execution modelsを深く勉強したこともないんだ.
でも理論的には、もしlanguageがstack-based（かstack machineにmappingできるなら）で、ISAがニーズをcoverできるなら、可能かもしれない.
今はPyXL’s ISAはPython’s patternsに合わせてtunedされてるけど、他のlanguages用にgeneralizeするのはdefinitely an interesting challengeだろうね.
Luaはfit the bill then definitelyだと思うよ.Edit: これ超面白いprojectだねって言いたかったんだ. custom toolchainsとかcompilation stepでpythonがどこで動くか最初はstruggleしたけど、重要なのはhardwareがvmみたいにdynamic aspects全部含めてrunしてるってこと. parent commentみたいに、wasm向けのもworth havingかなって思う.
それに加えて、WASM executionをexploreするのもinterestingかもね.
variable amountのmemoryをiterateするinstruction、例えばstringのconcatenatingとか、どう扱うの? そういうinstructionってinterruptible? virtual memoryないならinterruptible不要かもだけど.
memoryはallocateどうしてるの? Mallocとfreeをhardwareでやるのってpretty complexだよね.
C#が出た頃、誰かきっと.Net bytecodeをnatively executeするprocessorを作ると思ってたんだ. これついにどこかのlanguageでhappenedしたの見られて嬉しいよ.
Javaだと、Jazelleっていうのが少しあったよ. https://en.wikipedia.org/wiki/Jazelle.
ARM processorsのmodeじゃなくて、common JVM opcodesのsubsetをranするcomplete systemの方がEven betterだったよ. https://en.wikipedia.org/wiki/PicoJava
Some phonesにhardware Java executionあったっけ? my memory fail me?
Jazelleって呼ばれてるよ.
Sunも似たようなの作ろうとしてたよ、たしかJavaChipって呼ばれてたな。JavaStationsとかキオスク端末、携帯電話向けだったけど、全然流行らなかったんだ。
いや、あれはJava Co-Processorを積んだMotorola製プロセッサのMotorola製携帯だよ。Jazelleじゃないんだ。
例えばスマートカードとかでJavaがそういうのやったよね。過去の面白い珍しい例だ。
JavaCardは最後に調べた時は、ただの普通のインタプリタとして実装されてただけだよ。
大学で卒論として、Befungeの派生版でこういうこと（命令デコードを単純化するために文字セットを選ぶ）をやりたかったんだ。でも指導教官がもっと実用的なものをって譲らなかったんだよね。：（
リンクのことだけど、Befungeの面白い点は二次元PCが必要なことなんだ。空白スキップはO(1)らしいけど実装予定はなかった。でも、256x256バイトメモリで、一部を文字表示に直接メモリマップしたマシンを想像してたんだよ。
2006〜2008年頃にこういう製品あった気がするんだけど、見つかるのは.NET Micro Frameworkとかその後の.NET nano Frameworkだけ。2001年から.NET使ってるから勘違いかもだけど、当時のネット情報消えてるから存在したけど消えた可能性もあるね。
Netduinoってのはあったよ、でもあれはSTM32マイコン上でインタプリタが動いてただけで、CLRコードを直接実行する専用ハードウェアじゃなかったけどね。
