是否有必要总是用 C 语言编写 RTOS？为什么不能用java或其他技术编码..？？那是因为java中没有指针概念吗？
问问题
8386 次
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 被广泛使用，但它也有局限性，因为它不是为嵌入式应用程序或现在很常见的规模项目而设计的。主要限制包括：
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 回答
6
不是“必要的”，但更实用
作为一种可以使用 Java 的语言，它确实发生了各种古怪的案例。
但一些边缘案例和示威确实更像是“证明规则的例外”。
一般来说，Java 是一个用于业务逻辑而非操作系统内核的大型复杂系统。
如果我们还没有 C，Java 可能会朝不同的方向发展，或者朝多个方向发展。
但是我们确实有 C，它对于操作系统内核来说几乎是完美的，对于业务逻辑来说是一个相当大的挑战。
关于内核与 C 一样好 Java 的论点与应用程序中 C 与 Java 一样好的论点同样现实。经验，减去一些边缘示例，压倒性地证明了每种语言的优点。
于 2009-12-19T05:51:07.977 回答
5
根据定义，RTOS 必须支持确定性调度和执行。一般来说，低中断延迟和直接硬件访问也是一个理想的因素。Java 中使用的诸如垃圾收集、JIT 编译和字节码执行等技术使得这些目标难以实现。
Java 可以在实时系统中使用，但通常它在RTOS 上运行，而不是在其实现中使用。
尽管如此，建议 RTOS 总是用 C 实现同样是不真实的。任何系统级语言都适用，包括汇编程序。在大多数情况下，至少内核的某些部分无论如何都会在汇编程序中。C++ 将是一种合适的语言（很明显，因为它本质上是 C 超集），许多商业 RTOS 在任何情况下都有 C++ 包装器；我习惯性地为 RTOS 开发 C++ 抽象层以支持可移植性。
通常使用 C 的另一个原因是因为 C（通常是 C/C++）编译器通常是第一种且通常是唯一可用于新体系结构的语言（汇编程序除外）（现在经常以 GNU 编译器实现的形式） ）。因此，如果您希望能够将您的 RTOS 移植到最广泛的平台，那么使用最普遍的语言是有意义的。
于 2009-12-18T19:19:13.850 回答
3
我认为java为此目的最大的问题是自动垃圾收集。这是在 java 中创建实时系统的链接。
于 2009-12-18T09:37:39.840 回答
3
因为基于 C 语言的 RTOS 众所周知并且已经使用了几十年。对于许多特定情况，它们的行为是可预测的，您可以找到许多使用这些系统进行开发的专家。
我知道没有任何基于 Java 的 RTOS 达到了让生产安全关键实时应用程序的公司能够采用它的水平。
从技术上讲，没有反对基于 Java 的 RTOS 的论据，但有关该主题的研究、工程和产品尚未成熟。
于 2009-12-18T09:58:58.023 回答
3
是否有必要总是用 C 语言编写 RTOS？
不，您也可以在汇编程序、Ada 和其他一些程序中编写 RTOS。
为什么不能用java或其他技术编码..？？那是因为java中没有指针概念吗？
不。不可预测的代码执行时间。
于 2009-12-18T10:19:37.230 回答
2
Java 中有 Real Time，但它需要操作系统的支持。参见：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
如果有的话，那是因为指针。在 Java 中，除了基本数据类型之外的所有内容都分配在堆上，任何不是类似的变量都是int指针。这不是编写操作系统的好方法，因为它对大多数操作施加了一层间接性，而在操作系统中编写该层可能会杀死你。
操作系统内核是您想要优化和高性能的地方，因为您不知道将在其上运行什么。对于实时操作系统尤其如此，其中半毫秒的延迟可能至关重要。这需要真正熟悉 CPU 和其他硬件，以及编写高度微优化的代码的能力，这些代码将以极好的可预测性执行特定的事情。
出于这个原因，C 是构建 RTOS 内核的非常好的工具，而 Java 不是。这并不意味着你不能用 Java 做到这一点，但它会更难，而且可能不会那么成功。
我很好奇你为什么问这个问题。如果您使用的是 RTOS，那么它是用什么编写的并不重要。如果您想破解它，那么它是用什么编写的，但操作系统的概念和实现本身就足够难了学习一门新语言是微不足道的。（此外，如果您学习操作系统设计和实现，您几乎可以肯定会发现您使用的资源将使用 C 作为教学语言。）
于 2009-12-21T22:37:27.763 回答
1
RTOS 并不总是用 C 编写的。通常是这样，但在 ThreadX 中，我相信他们使用汇编。
于 2011-01-27T23:42:18.803 回答
-3
像 Java 这样的垃圾收集语言非常不适合实时编程。其原因应该是显而易见的。
于 2009-12-18T09:38:20.513 回答
-3
是否有必要总是用 C 语言编写 RTOS？
不，例如，有用 Lisp 或 Smalltalk 编写的 RTOS。
为什么不能用java或其他技术编码..？？
是什么让你认为它不能？
那是因为java中没有指针概念吗？
不，这是因为有一个神话，操作系统只能用 C 语言编写。一个神话可以被简单地证明是错误的，但仍然拒绝消亡。
这个神话是如此普遍，以至于想要编写新操作系统的人都不敢尝试 C 以外的任何东西。
于 2009-12-18T13:42:45.823 回答