2

私はVMをゲームに組み込むことを検討しており、ロボット、モーター、センサーなど。私の主な関心事は、自分でロールする場合はコンパイラー/アセンブラーを作成する必要があることです。すでに存在するツール、または最も単純な形式のツールを使用して、コンパイルできるCコンパイラを使用するとよいでしょう:-p。

私は本当にここで車輪の再発明をしたくありませんが、仮想世界を走り回る何千ものこれらも必要なので、できるだけシンプルで高速でなければなりません。ある人がすでに述べたように、私はタイミングやバスなどの現実世界の問題も気にしません。彼らの仮想時計はかなり遅いものに制限されると思います。最終的には、ネイティブコンパイルを調べて、それらをさらに高速に実行する必要がありますが、今のところ、一般的な概念実証を得るためにプロトタイプをまとめているだけです。

入力として、円筒形の本体（16個、おそらく32個）の周りに取り付けられた距離、光、材料、およびタッチセンサーを計画し、次に、各側の一種のホイールを制御するための方向出力用の2つのモーターを計画しています。基本的に、処理はそれほど精力的ではなく、世界は十分に単純であるため、マシンは単純なタスクで多くの処理能力を投入する必要がありません。

メモリに関しては、マップの作成や統計の収集に介入することなく、数日間そのままにしておくのに十分なデータを保存できるようにしたいと思います。私は8ビットが処理やメモリのためにそれをカットするのは好きではありませんが、16ビットは間違いなく競争相手です。32ビットと64ビットはそれをプッシュするだけであり、それぞれ1MBを超えるメモリを搭載する方法はありません。おそらく256〜512kに近いでしょう。（ビル1は640kで十分だと言ったのに、なぜ私はできないのですか!!）

4

5 に答える 5

6

私は、約 16K の RAM を搭載した組み込みコントローラーで VM 言語を実行したいという友人のために、Wrenを作成しました。(ただし、記述されているコードでは、プロセスごとに最大 64k まで許容されます。) これには、馬鹿げた小さなプログラミング言語用のコンパイラが含まれています。それはすべて、非常に基本的なものであり、あまり使用されていませんが、最初の段落で説明したとおりです。

于 2008-11-05T17:49:08.567 に答える
5

FORTH の「仮想マシン」は非常にシンプルです。16 ビット アドレス空間 (通常)、16 ビット データ ワード、2 つのスタック、メモリ。Loeliger の「Threaded Interpretive Languages」は、Z80 上で FORTH インタープリターを構築する方法について多くのことを教えてくれます。

于 2010-06-12T21:02:04.090 に答える
2

実世界に根ざしたものが必要な場合、最もよく使用される組み込み RISC マイクロコントローラーの 1 つは PIC ファミリーです。グーグルはいくつかのエミュレーターを提供していますが、ほとんどの場合、ソースが利用できるとは思いません。

もう 1 つの可能性は QEMU で、これはすでにいくつかの ARM の種類をエミュレートしています。

もちろん、実際のデバイスをエミュレートすることに興味がない場合は、独自のデバイスを作成する方がはるかに簡単でパフォーマンスが向上します。必要なものだけを使用し、状態フラグ、オーバーフロー ビット、バス幅の制限、RAM タイミングなどの混乱に陥ることはありません。

于 2008-11-05T17:05:12.087 に答える
1

ゲーム プログラムやその他のアプリケーションを作成する多くの人々は、アプリケーションに言語を組み込んで、ユーザーが小さなプログラムを作成できるようにします。

私が知る限り、最も人気のある組み込み言語は、非常に大雑把に言えば、最も人気のある言語 (ただし、「人気が高い」ということは必ずしも「優れている」という意味ではありません) のようです。

  • この特定のアプリケーション用にカスタム設計され、他では使用されないドメイン固有言語
  • ルアア_
  • Tcl
  • Python a b 、多くの場合、PyMite cなどの単純化されたサブセット
  • 前方へ
  • JavaScript a
  • 舌足らずの発音
  • AngelScript a
  • XPL0 a b
  • リスa
  • ハスケルa b
  • NPCI (Nano Pseudo C Interpreted) a
  • ロボトーク
  • いくつかのハードウェア マシン言語を解釈する (なぜこれが最も人気のない選択肢なのでしょうか? 以下で説明する正当な理由により)。

「スクリプト言語をゲームに追加するにはどうすればよいですか?」などの特定の質問については、Gamedev StackExchange を確認してください。.

「組み込み言語」とタグ付けされた StackOverflow に関する質問のいくつかを確認してください。「組み込み言語の選択」、 「 ソフトウェア内のスクリプト作成に使用できる優れた組み込み可能言語は何ですか?」など。 「組み込み言語として Lua に代わるものはありますか?」 「Lua と Python のどちらのゲーム スクリプト言語を使用するのが適していますか?」など

これらの言語の多くの実装では、内部である種の バイトコードを使用しています。多くの場合、JavaScript などの同じ高水準プログラミング言語の 2 つの異なる実装は、内部で 2 つの完全に異なるバイトコード言語を使用します ( a )。多くの場合、複数の高レベル プログラミング言語が同じ基になるバイトコード言語にコンパイルされます。たとえば、Python の Jython 実装、JavaScript の Rhino 実装、Tcl の Jacl 実装、JScheme およびその他の Scheme のいくつかの実装、Pascal のいくつかの実装などです。すべてが同じ JVM バイトコードにコンパイルされます。

詳細

ハードウェアの機械語を解釈するのではなく、スクリプト言語を使用するのはなぜですか?

なぜ「ハード層とソフト層を交互にする」のですか？簡素化と迅速な開発を実現します。

より迅速な開発

一般に、人々はコンパイル言語よりもスクリプト言語を使用した方が、作業が速くなります。

一般に、最初のプロトタイプを動作させる方がはるかに高速です。インタープリターは、機械語が明示的に書き出すことを強制する舞台裏の一連のものを処理します: 変数の初期値をゼロに設定する、サブルーチン プロローグおよびサブルーチン エピローグ コード、malloc、realloc、free および関連するメモリ管理機能、コンテナがいっぱいになったときのコンテナのサイズの増加など。

最初のプロトタイプがあれば、新しい機能を追加する方が速くなります。スクリプト言語は、コンパイルされた言語の編集-コンパイル-実行-デバッグ サイクルの「コンパイル」段階を回避するため、編集-実行-デバッグ サイクルが高速です。

シンプルさ

埋め込み言語 language を次の 2 つの点で「シンプル」にしたいと考えています。

  • ユーザーが概念的に些細なタスクを実行する小さなコードを書きたい場合、"Hello, $USER " バッファ オーバーフローなし。

  • 言語を実装しているので、実装が簡単なものが必要です。おそらく、週末に簡単なインタープリターをノックアウトできるいくつかの簡単な基本命令と、最小限の調整で再利用できるある種の既存のコンパイラーです。

人々が CPU を構築するとき、ハードウェアの制約によって常に命令セットが制限されます。多くの概念的に「単純な」操作 (人々が常に使用するもの) を実装するには、多くの機械語命令が必要になります。

組み込み言語には、これらのハードウェア制限がないため、(人間にとって) 概念的に単純に見えることを実行する、より複雑な「命令」を実装できます。これにより、多くの場合、上記の両方の方法でシステムが単純になります。

  • 言語で直接書いている人 (またはその言語のコンパイラを書いている人) は、最終的にコードの記述が大幅に少なくなり、コードのデバッグに 1 ステップずつ費やす時間が少なくなります。

  • このような高レベルの操作ごとに、複雑さをコンパイラからインタプリタ内の命令の実装に移します。コンパイラーが中間言語の一部の高レベル操作を短いループに分割する (そして実行時にインタープリターでそのループを繰り返しステップ実行する) のではなく (コードを記述する) 代わりに、コンパイラーは中間言語で 1 つの命令を発行します (そして、その中間「命令」のインタープリターの実装で同じ一連の操作を記述します)。コンパイルされた言語 ("内部" の複雑な命令) に実装されたすべての CPU 集中型処理により、非常に単純なインタープリターが十分に高速であることがよくあります。(つまり、多くの時間を JIT の構築や他の方法で高速化しようとするのに費やすことを避けます)。

これらの理由やその他の理由から、多くのゲーム プログラマーは「組み込み言語」として「スクリプト」言語を使用します。

(ハビエルはすでに「組み込みスクリプト言語を使用する」ことを推奨していたので、これがハードウェア マシン言語の解釈に代わる優れた代替手段である理由と、特定のスクリプト言語が適切でない場合に代替手段を指摘する理由について、長々と言い争うようになりました。適切）。

于 2012-06-17T17:34:30.627 に答える
1

シンプルにしたい場合は、Manchester Mark I を検討してください。この PDFの 15 ページを参照してください。マシンには 7 つの命令があります。そのためのインタープリターを作成するには、約 1 時間かかります。残念ながら、説明書はかなり限られています (これが、マシンのほぼ完全な仕様が 1 ページに収まる理由です)。

ハビエルの独自のアプローチは非常に実用的です。小さなマシンの設計と作成は、もしそうなら 2 日間の作業です。数年前にプロジェクト用に小さな VM を構築しましたが、単純なビジュアル デバッガーで VM を作成するのに 2 日かかりました。

また、RISCである必要がありますか？たとえば、オープン ソース エミュレーターが存在する 68K を選択でき、68K は gcc のよく知られたターゲットでした。

于 2008-11-05T17:13:22.680 に答える