4

RTOS は必ず C 言語でコーディングする必要がありますか? Javaやその他のテクノロジーでコーディングできないのはなぜですか..?? それは、Java にポインターの概念がないためですか?

4

16 に答える 16

16

ガベージ コレクションは、Java がリアルタイムであることに反対する大きな理由です。JITも別ですが、克服できる可能性があります。

ただし、一般に、C は効果的に移植可能なアセンブリであり、非常に予測可能なランタイム パフォーマンスを提供します。これは、信頼性の高いリアルタイム実行に不可欠です。

于 2009-12-18T09:38:05.743 に答える
10

おそらく、RTOS 開発者は C++ を十分に理解していないためです。

組み込みシステムにおける C++: 神話と現実

C++ にはオーバーヘッドとコストがかかるため、組み込みシステム プログラミングには何らかの形で適さない、C の制御と簡潔さに欠ける、または一部のニッチなアプリケーションには適しているかもしれないが、C を言語として置き換えることは決してないと認識する人もいます。組み込みシステム向けの選択肢。

これらの認識は間違っています。コンパイラやその他のツールが適切な場合、組み込みシステムの実装言語として C++ は常に C よりも優先されます。C が行うすべてのことを行う一方で、C では表現、カプセル化、再利用の機会が増え、C では非現実的なサイズと速度の改善さえ可能になります。

> では、なぜこれらの認識が持続するのでしょうか? 主な理由は、人々が意見を述べるとき、C++ よりも C について多くのことを知っているからです。彼らは何冊かの本を読み、いくつかのコードを書き、C++ の機能を使用する能力はありますが、内部で何が起こっているかについての知識、つまりソースを入力している間、またはコードを作成している間に逆アセンブリを視覚化できるほどの知識が不足しています。デザイン。

組み込み設計で C の代替として C++ を使用するためのガイドライン

組み込みソフトウェア アプリケーションは、最も一般的には C で記述されます。長年にわたり、C++ は自然な後継者と見なされ、より受け入れられてきましたが、その使用の増加は予想よりもはるかに遅くなっています。

これにはいくつかの理由があります。第一に、組み込み開発者は非常に保守的で、目新しいソリューションよりも実績のあるソリューションを使用することを好みます。

体験レッスンもあります。多くの開発者が組み込みアプリケーションに C++ を使用しようとして失敗しました。このような失敗は、開発ツールの欠点に起因する場合もありますが、ほとんどの場合、「組み込みシステムをデスクトップ コンピュータのように扱う」という言葉の不適切な使用が原因です。

C の制限 C は広く使用されていますが、組み込みアプリケーションや現在一般的な規模のプロジェクト向けに設計されていないため、制限があります。主な制限事項は次のとおりです。

1) C は非常に強力で柔軟性があるため、危険な場合があります。

2) プログラマーは非常に系統的で規律ある必要があります

3) プログラマーは、プログラムが低レベルおよび高レベルでどのように動作するかを理解する必要があります (したがって、大規模なプロジェクトは保守が困難です)。

4) プログラマーには、アプリケーションに関する専門知識が必要です。

ただし、C++ には強力なオブジェクト指向機能があり、C の制限に対処するのに大いに役立ちます。

1) 高度な専門知識の領域をカプセル化し、非専門家から「オブジェクト」に隠します。(テスト ケースは、このシリーズの第 2 部で後ほど専門知識のカプセル化を示します)。

2) 専門家でなくてもオブジェクトを直感的に使用して、概念設計を高レベルで実装できます。

于 2010-02-07T13:33:49.347 に答える
9

リアルタイム システムは他の言語でもプログラミングできます。たとえば、JavaにはJava RTSシステムがあります。

他の回答とは対照的に、リアルタイムのガベージ コレクションには妥当な量の作業があります。ただし、これらは通常のディストリビューションにはバンドルされていません。

問題は、他の言語には通常、決定論と信頼性の達成を困難にする機能 (従来のガベージ コレクション、JIT、実行時の最適化など) があることです。

于 2009-12-18T09:37:53.853 に答える
8

まず、RTOS は C だけでコーディングされているわけではありません。他の言語でコーディングすることもできます。ただし、RTOS に使用される言語は、決定論的な動作を提供する必要があります。これは、特定のアクションの待ち時間が常に特定の時間未満でなければならないことを意味します。これは、たとえばガベージ コレクションを除外します。ガベージ コレクションは、ほとんどの実装で、すべてのスレッドの実行を未定の時間停止します。

于 2009-12-18T09:40:59.680 に答える
6
  • RTOS-es が通常実行されるすべてのハードウェアに対して、高度に最適化された C コンパイラを利用できます。
  • 非常に低レベルの最適化を C コードに含めることができる相対的な容易さ。
  • 多くの便利な低レベル システム ツールの C コードが利用できるため、簡単に組み込むことができます。
于 2009-12-18T09:49:48.067 に答える
5

定義上、RTOS は決定論的なスケジューリングと実行をサポートする必要があります。一般に、割り込みレイテンシが低く、ハードウェアへの直接アクセスも望ましい要素です。ガベージ コレクション、JIT コンパイル、バイトコード実行などの Java で使用されるテクノロジは、これらの目標の達成を困難にします。

Java はリアルタイム システムで使用される場合がありますが、通常は実装で使用されるのではなく、RTOS上で実行されます。

とはいえ、RTOS が常に C で実装されていると示唆するのも同様に正しくありません。アセンブラーを含む任意のシステム レベル言語が適しています。ほとんどの場合、少なくともカーネルの一部はアセンブラーにあります。C++ は適切な言語です (本質的には C のスーパーセットであるため、明らかに)。多くの商用 RTOS にはいずれにしても C++ ラッパーがあります。移植性をサポートするために、RTOS 用の C++ 抽象化レイヤーを習慣的に開発しています。

C が一般的に使用されるもう 1 つの理由は、C (多くの場合 C/C++) コンパイラが一般に、新しいアーキテクチャで使用できる最初の、そして多くの場合唯一の言語 (アセンブラ以外) であるためです (最近では GNU コンパイラ実装の形式でよく使用されます)。 )。したがって、RTOS を最も多くのプラットフォームに移植できるようにしたい場合は、最もユビキタスな言語を使用するのが理にかなっています。

于 2009-12-18T19:19:13.850 に答える
3

C ベースの RTOS はよく知られており、何十年にもわたって使用されてきました。それらの動作は多くの特定の状況で予測可能であり、これらのシステムで開発するための多くの専門家を見つけることができます.

私は、Java ベースの RTOS が、安全性が重要なリアルタイム アプリケーションを作成している企業が採用するレベルに達していないことを知っています。

技術的には、Java ベースの RTOS に反対する議論はありませんが、このテーマに関する研究、エンジニアリング、および製品はまだ成熟していません。

于 2009-12-18T09:58:58.023 に答える
3

この目的でのJavaの最大の問題は、自動ガベージコレクションだと思います。Java でのリアルタイム システムの作成に関するリンクを次に示します。

于 2009-12-18T09:37:39.840 に答える
3

RTOS は必ず C 言語でコーディングする必要がありますか?

いいえ。RTOS は、アセンブラー、Ada、およびその他のいくつかでもコーディングできます。

Javaやその他のテクノロジーでコーディングできないのはなぜですか..?? それは、Java にポインターの概念がないためですか?

いいえ。コードの実行時間は予測できません。

于 2009-12-18T10:19:37.230 に答える
2

Java には Real Time がありますが、OS のサポートが必要です。参照: http://java.sun.com/javase/technologies/realtime/index.jsp

于 2009-12-18T09:43:35.680 に答える
1

Cは、オペレーティングシステムを作成するために設計されたため、「ポータブルアセンブラ」という一般的な表現であるため、その目的で使用されることが期待されます。

リアルタイムのJavaが必要な場合は、Sunが商用サービスを提供しています。

于 2009-12-18T10:30:54.900 に答える
1

RTOS は常に C で記述されているとは限りません。通常はそうですが、ThreadX ではアセンブリを使用していると思います。

于 2011-01-27T23:42:18.803 に答える
1

どちらかといえば、それはポインタのせいです。Java では、基本的なデータ型を除くすべてがヒープに割り当てられ、そうでない変数はすべてintポインターです。これは、オペレーティング システムを作成するのに適した方法ではありません。これは、ほとんどの操作に対して 1 つの間接レイヤーを課すためです。

OS カーネルは、何が実行されるかわからないため、最適化と高性能が必要な場所です。これは、0.5 ミリ秒の遅延が重要になる可能性があるリアルタイム OS に特に当てはまります。これには、CPU やその他のハードウェアとの親しみやすさと、特定のことを優れた予測可能性で実行する高度にマイクロ最適化されたコードを作成する能力が必要です。

このため、C は RTOS カーネルを構築するための非常に優れたツールですが、Java はそうではありません。それは、Java でそれができないという意味ではありませんが、それはより困難であり、おそらくそれほど成功しないでしょう。

なぜ質問をするのか興味があります。RTOS を使用している場合、それが何で書かれているかは問題ではありません。ハッキングしたい場合は、それが何で書かれているかは問題ではありませんが、OS の概念と実装自体が十分に難しいため、新しい言語を学ぶことは簡単なことです。(さらに、OS の設計と実装を研究すれば、使用するリソースが C を教育言語として使用することがほぼ確実にわかります。)

于 2009-12-21T22:37:27.763 に答える
-3

RTOS は必ず C 言語でコーディングする必要がありますか?

いいえ。たとえば、Lisp や Smalltalk で書かれた RTOS があります。

Javaやその他のテクノロジーでコーディングできないのはなぜですか..??

できないと思う根拠は?

それは、Java にポインターの概念がないためですか?

いいえ、それは、オペレーティング システムは C でしか記述できないという神話があるからです。この神話は、自明に誤りであることが証明されますが、それでも死ぬことはありません。

この神話は非常に広まっているため、新しい OS を書きたいと思っている人は、C 以外のものを試すことを恐れています。

于 2009-12-18T13:42:45.823 に答える
-3

Java のようなガベージ コレクション言語は、リアルタイム プログラミングにはまったく適していません。この理由は明らかです。

于 2009-12-18T09:38:20.513 に答える