最近、単純なアセンブリ言語で実装された Forth プログラミング言語のインタプリタであるJONESFORTHに出くわしました。
この実装は、言語をアセンブリ言語で実装する方法を示しているため、興味深いと思いますが、言語の実装は移植性の重大なトレードオフになる可能性があることは理解しています。
それで、アセンブリ言語で実装された他のプログラミング言語があり、そのソースがまだ利用可能である (そして、まだ活発に開発されている可能性さえある) かどうか疑問に思いました。
最近、単純なアセンブリ言語で実装された Forth プログラミング言語のインタプリタであるJONESFORTHに出くわしました。
この実装は、言語をアセンブリ言語で実装する方法を示しているため、興味深いと思いますが、言語の実装は移植性の重大なトレードオフになる可能性があることは理解しています。
それで、アセンブリ言語で実装された他のプログラミング言語があり、そのソースがまだ利用可能である (そして、まだ活発に開発されている可能性さえある) かどうか疑問に思いました。
アセンブリで言語実装を記述することは可能ですが、ほとんどの言語では、さまざまな理由からそうするのはお勧めできません。アセンブリ コードは、開発と保守が難しいことで有名であり、定義上、移植性がありません。
とはいえ、一部の言語では、実装を作成するのが非常に簡単です。
1.0以降のTurboPascalのいくつかのバージョンは、アセンブリ言語で記述されています。これは、エディター、コンパイラー、デバッガー、およびコンパイル済みプログラムを当時の64 KB RAMに収める唯一の方法であり、これまでにない驚異的な編集-コンパイル-デバッグ速度を提供しました。
Pico Lisp は最近 (ここ数年)、C から x86-64 アセンブラーに切り替えました。それは私が考えることができる唯一の例であり、「近代」の時代に行われたものです. アセンブラからブートストラップされた古い Lisp がまだ使用されています。ちょっと待ってください。最近、誰かが ARM アセンブラでスキームを書きました (http://armpit.sourceforge.net/index.html)。なぜ彼らがこんな馬鹿げたことをしたのかわからないし、詳しく調べたこともない。もちろん、C で記述し、いくつかの asm 関数を追加して call/cc などを実装することは非常に一般的です。
1980 年代の BDS C コンパイラは 8080 アセンブラで書かれており、ソース コードは数年前にリリースされましたが、ほとんどが歴史的なものです。
最終的に、すべての言語はアセンブラーで実装されます。C コンパイラーは、何らかの形で、どこかで + をアセンブラー命令にマップする必要があります。アセンブラー カーネル内の言語の部分の大きさと、言語自体で定義されている言語の部分の大きさには大きなばらつきがあります。jonesforth を見ると、カーネルの一部は、アセンブラー ファイルであっても、実際にはアセンブラー コードではなく Forth コードであることがわかります。
したがって、基準は、メイン プログラムの言語がアセンブラーであるか、言語自体であるかということになる可能性があります。より重要なことは、ある言語が別の言語を構築する必要があるかどうかです。たとえば、Pascal での Lisp 実装、C を使用して実装された Gforth などです。いくつかの慣行は時代遅れです。コンパイラのプロセッサの新機能についていくには、コンパイラがそれ自体で書かれているかアセンブリで書かれているかにかかわらず、アセンブリに関する深い知識が必要です。
ソースがある限り、言語は死んでいません。FIG-Forth (1980) を見ることができます。jonesforth は、16/32/64 ビット用の i86 アセンブラ Forth である私の ciforth から着想を得ています。
特に、私が特に教育目的で作成した Forth in アセンブラである「yourforth」をお勧めします。演習がありますが、まだ完了していません: https://bitbucket.org/avanderhorst/yourforth
純粋にアセンブリではありませんが、vm と luajit の他のいくつかのセクションは、複数のプラットフォーム (主に x86) 用に、純粋にそれが提供する速度のために、マクロ化されたアセンブリで記述されています (mike paul には他の理由があるかもしれませんが、私はこれが主なもの)。マクロ プロセッサも同様にカスタム ビルドされていますが、lua を使用しています。