5

私はfunarg 問題についてこの論文を読んでいました。これは実際にはレキシカル クロージャの環境を維持する問題です。これは古い論文であり、著者の結論が今でも当てはまるかどうかはわかりませんが、ダイナミック スコープではなくレキシカル スコープを使用するには、従来の C スタイルのスタックを放棄し、代わりにツリー構造を使用する必要があることを彼は強く示唆しています。ヒープから割り当てられた環境の。

これにより、ハードリアルタイムシステムでレキシカルスコープのクロージャーを持つことが不可能になりますか? 待ち時間がマイクロ秒単位で測定されるリアルタイム組み込みシステムでは、ヒープ割り当ては、非決定論的な待ち時間が発生するため、通常は禁止されています。

これは私の怠惰な好奇心でした。なぜなら、私は主に C が事実上の言語であるファームウェア開発者として生計を立てているからです。より洗練された言語で無料で提供されることをさせてください。その結果、ハードリアルタイム組み込みマイクロコントローラーベースのシステム専用の micro-lisp コンパイラーを実装できないかと考え始めました。

余談ですが、私は最近、クロージャーとオブジェクトがどのように同等であるかなどの深いトピックについて大きな洞察を得ており、ストールマンやリッチ ヒッキー、ポール グレアムなどの人物に畏敬の念を抱いています。Lisp をゼロから実装することは、私には困難な作業のように思えます。どこから始めればよいかわかりにくい。(おそらく、McCarthy のオリジナルの eval 関数 IDK の PG による実装によるものです)。とにかく脱線します。

4

2 に答える 2

3

レキシカル スコープは明らかに「ハード リアルタイム」で可能です。結局のところ、C をリアルタイム アプリケーションに使用していると言いますが、Cレキシカルスコープ言語です。私の推測では、あなたは実際にはレキシカル スコープではなく、ファースト クラスの関数に関心を持っているのではないでしょうか。と仮定すると、ファーストクラスの関数を効率的に処理するための既知のコンパイル手法がたくさんあります。

まず、教科書などで目にするのは、ほとんどの場合、通常のツリー型の環境を実行することですが、実際には、関数が値として使用されていなければ、まったく必要ありません。実質的にすべての適切な関数型言語コンパイラは、そのようなコードを識別し、代わりにスタックを使用するため、割り当てのオーバーヘッドはありません。(この時点で、これは、C で記述した種類のものに制限する場合、割り当ては不要であることを意味することに注意してください。) 次に、割り当てを減らすための追加の方法がたくさんあります。たとえば、次のようなものを検討してください(lambda (x) (* x 9))。 - この関数は実際には空き識別子を閉じないため、コンパイラは持ち上げますそれを一番上に置くので、関数の単一のコピーがあり、ここでも割り当てはありません。(関連ノート: この最適化により、C が提供する以上のものが既に得られていますが、まだ割り当てはありません。)

割り当てを回避する追加の最適化がたくさんありますが、もちろん、新しいクロージャーを本当に割り当てる必要がある場合もあります。しかし、これらの場所は静的に識別可能であり、そのような割り当てを本当に気にするのであれば、そのような割り当てについて警告するコンパイラをハックすることは難しくありません。そのような言語がいくつかあります。たとえば、非常に低レベルのpreschemeであるGOALを参照してください。. しかし、IME はほとんどの人がすぐにコツをつかみ、割り当てがどこで行われるかが明らかになってきます。そのため、高水準言語の利点が得られ、最適化したいコードに到達すると、割り当てが行われる場所を簡単に確認できます。 、通常の方法で簡単に回避できます。(そしてもちろん、これはすべて割り当ての最適化とは無関係です。)

于 2011-04-30T17:01:34.027 に答える
1

リアルタイムアロケーターをいくつか見つけたので、そう言います。リアルタイムでのレキシカルスコープが可能です:

http://rtportal.upv.es/rtmalloc/

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.106.441&rep=rep1&type=pdf

あなたの余談に加えて、私自身のmicro-lispを書く前に、問題の組み込みシステムのluaを見つけたり移植したりしようとします。それは非常に小さく、LISP の多くを提供します: ファーストクラスの関数、クロージャ、継続ではなくコルーチンです。

ルアは小さい

Lua をアプリケーションに追加しても、アプリケーションが肥大化することはありません。ソース コード、ドキュメント、およびサンプルを含む Lua 5.1.4 の tarball は、圧縮で 212K、非圧縮で 860K 必要です。ソースには約 17000 行の C が含まれています。Linux では、すべての標準 Lua ライブラリでビルドされた Lua インタープリタは 153K、Lua ライブラリは 203K を使用します。

ルアは無料です

Lua は無料のオープンソース ソフトウェアであり、非常に自由度の高いライセンス (よく知られた MIT ライセンス) の下で配布されています。営利目的を含むあらゆる目的で、完全に無料で使用することができます。ダウンロードして使用するだけです。

于 2011-04-30T12:54:08.647 に答える