是否需要一直用 C 语言编写 RTOS？为什么不能用java或其他技术编码..？？是因为java中没有指针的概念吗？
【问题讨论】：
RTOS 并不总是用 C 编写的。通常是这样，但在 ThreadX 中我相信他们使用汇编。
【讨论】：
因为 RTOS 开发人员很可能不太了解 C++。
C++ in Embedded Systems: Myth and Reality
有些人认为 C++ 有开销 以及以某种方式呈现它的成本 不适合嵌入式系统 编程，它缺乏控制 和 C 的简洁性，或者说，虽然它 可能适合某些利基市场 应用程序，它永远不会取代 C 作为嵌入式语言的首选 系统。
这些看法是错误的。在哪里 编译器和其他工具是 足够，C++ 总是比 C 作为实现语言 嵌入式系统。在做的时候 C所做的一切，它提供 更多的表达机会， 封装，重用，甚至 允许尺寸和速度改进 在 C 中是不切实际的。
> 那么，为什么会有这些看法 坚持？主要原因是当 人们形成他们的意见，他们知道 关于 C 的内容比关于 C++ 的内容要多得多。 他们读过一些书，写过 一些代码，并能胜任使用 C++ 的特性，但缺少 了解正在发生的事情 引擎盖，允许的熟悉度 一个可视化的反汇编，同时 输入源代码甚至同时 制定设计。
Guidelines for using C++ as an alternative to C in embedded designs
嵌入式软件应用程序最常使用 C 语言编写。多年来，C++ 被视为自然的继任者，并获得了更大的接受，但增加 它的使用速度比预期的要慢得多。
造成这种情况的原因有很多。首先，嵌入式开发人员相当 保守，更喜欢使用经过验证的解决方案而不是新颖的解决方案“如果它 没坏，别修”。
还有经验教训。许多开发人员尝试使用 C++ 嵌入式应用程序并失败。此类故障有时可能归因于 开发工具的缺点，但最常见的是不恰当地使用 语言“将嵌入式系统视为台式计算机”是罪魁祸首。
C 的局限性 尽管 C 被广泛使用，但它也有局限性，因为它不是为嵌入式而设计的 应用程序或用于现在司空见惯的规模项目。主要限制包括：
1) C 语言非常强大和灵活，因此可能很危险。（它的级别很低 能力——对嵌入式有用，但也代表了许多陷阱 不小心。）
2) 程序员需要非常有条不紊和自律
3) 程序员需要了解程序在低层和高层（大 项目因此难以维护）
4) 程序员需要应用程序的专业知识
但是，C++ 具有强大的面向对象功能，可以显着帮助 解决 C 的局限性：
1) 它将非专家的高专业知识领域封装并隐藏到“对象”中； （一种 测试用例将在本文的第 2 部分稍后演示专业知识的封装 系列）。
2) 非专家可以直观地使用对象来实现概念设计 高层
【讨论】：
【讨论】：
如果有的话，那是因为指针。在 Java 中，除了基本数据类型之外的所有内容都分配在堆上，任何不是 int 之类的变量都是指针。这不是编写操作系统的好方法，因为它对大多数操作施加了一层间接性，而在操作系统中编写该层可能会杀死你。
操作系统内核是您想要优化和高性能的地方，因为您不知道会在其上运行什么。对于实时操作系统尤其如此，其中半毫秒的延迟可能至关重要。这需要真正熟悉 CPU 和其他硬件，以及编写高度微优化的代码的能力，这些代码将以极好的可预测性执行特定的事情。
因此，C 是构建 RTOS 内核的非常好的工具，而 Java 不是。这并不意味着你不能用 Java 做到这一点，但它会更难，而且可能不会那么成功。
我很好奇你为什么问这个问题。如果您使用的是 RTOS，那么它是用什么编写的并不重要。如果您想破解它，那么它是用什么编写的，但操作系统的概念和实现本身就足够难了学习一门新语言是微不足道的。 （此外，如果您学习操作系统设计和实现，您几乎可以肯定会发现您使用的资源将使用 C 作为教学语言。）
【讨论】：
作为一种可以使用 Java 的语言，它确实发生了各种古怪的情况。
但一些边缘案例和示范确实更多“证明规则的例外”。
一般来说，Java 是一个用于业务逻辑而非操作系统内核的大型复杂系统。
如果我们还没有 C，Java 可能会朝不同的方向发展，或者朝多个方向发展。
但我们确实有 C，它对于操作系统内核来说几乎是完美的，但对于业务逻辑来说是一个相当大的挑战。
对于内核而言，Java 与 C 一样好的论点与对于应用程序而言 C 与 Java 一样好的论点几乎一样现实。经验，减去一些边缘示例，压倒性地证明了每种语言的优点。
【讨论】：
根据定义，RTOS 必须支持确定性调度和执行。一般来说，低中断延迟和直接硬件访问也是一个理想的因素。 Java 中使用的垃圾回收、JIT 编译和字节码执行等技术使这些目标难以实现。
Java 可用于实时系统，但通常在 RTOS 上运行，而不是在其实现中使用。
话虽如此，但建议 RTOS 始终用 C 实现同样不正确。任何系统级语言都适用，包括汇编程序。在大多数情况下，至少内核的某些部分无论如何都会在汇编程序中。 C++ 将是一种合适的语言（很明显，因为它本质上是 C 超集），许多商业 RTOS 在任何情况下都有 C++ 包装器；我习惯性地为 RTOS 开发 C++ 抽象层以支持可移植性。
通常使用 C 的另一个原因是因为 C（通常是 C/C++）编译器通常是第一种并且通常是唯一可用于新架构的语言（汇编程序除外）（现在经常以GNU 编译器实现）。因此，如果您希望能够将您的 RTOS 移植到最广泛的平台，那么使用最普遍的语言是有意义的。
【讨论】：
是否需要一直用 C 语言编写 RTOS？
没有。例如，有用 Lisp 或 Smalltalk 编写的 RTOS。
为什么不能用 java 或其他技术进行编码..？？
是什么让你认为它不能？
是因为java中没有指针的概念吗？
不，这是因为有一个神话，操作系统只能用 C 编写。一个神话可以被简单地证明是错误的，但仍然拒绝死亡。
这个神话是如此普遍，以至于想要编写新操作系统的人都不敢尝试 C 以外的任何东西。
【讨论】：
C 是为编写操作系统而设计的，因此有“可移植汇编程序”的常见措辞，因此可以预期它被用于此目的。
如果您想拥有实时 Java，Sun 提供了商业产品。
【讨论】：
是否需要一直用 C 语言编写 RTOS？
没有。您也可以在汇编程序、Ada 和其他一些程序中编写 RTOS。
为什么不能用 java 或其他技术编码..？是因为java中没有指针的概念吗？
没有。代码执行时间不可预测。
【讨论】：
因为基于 C 语言的 RTOS 广为人知，并且已经使用了数十年。它们的行为在许多特定情况下是可以预测的，您可以找到许多使用这些系统进行开发的专家。
据我所知，没有任何基于 Java 的 RTOS 达到了制造安全关键实时应用程序的公司会采用它的水平。
从技术上讲，没有人反对基于 Java 的 RTOS，但有关该主题的研究、工程和产品尚不成熟。
【讨论】：
实时系统也可以用其他语言进行编程。例如，Java 有一个Java RTS System。
与其他答案相反，实时垃圾收集方面的工作量是合理的。但是，这些不会捆绑在您的典型发行版中。
令人担忧的是，其他语言通常具有难以实现确定性和可靠性的特性，例如传统的垃圾收集、JIT、运行时优化等。
【讨论】：
Java 中有 Real Time，但它需要操作系统的支持。 见：http://java.sun.com/javase/technologies/realtime/index.jsp
【讨论】：
起初，RTOS 不仅仅是用 C 编码的。它们也可以用其他语言编码。然而，用于 RTOS 的语言需要提供确定性的行为。这意味着特定操作的延迟必须始终低于特定时间量。这排除了例如垃圾收集，在大多数实现中它将停止所有线程的执行一段不确定的时间。
【讨论】：
像 Java 这样的垃圾收集语言非常不适合实时编程。原因应该很明显。
【讨论】：
垃圾收集是 Java 不支持实时的重要原因。 JIT 是另一个，但它可以被克服。
一般来说，C 是有效的可移植程序集，可提供非常可预测的运行时性能，这对于可靠的实时执行至关重要。
【讨论】：
我认为java为此目的最大的问题是自动垃圾收集。这是一个 link 在 java 中创建实时系统。
【讨论】：