为啥 RTOS 只用 c 编码？

Posted 2023-02-19

【中文标题】为啥 RTOS 只用 c 编码？

【英文标题】：why are RTOS coded only in c?为什么 RTOS 只用 c 编码？

【发布时间】：2010-12-27 23:41:16

【问题描述】：

是否需要一直用 C 语言编写 RTOS？为什么不能用java或其他技术编码..？？是因为java中没有指针的概念吗？

【问题讨论】：

老实说大多数操作系统都是用 C RT 编写的

他们不是。请参阅 IBM 节拍器：domino.research.ibm.com/comm/research_projects.nsf/pages/…

@jk：还有原因：C 非常适合用来编写 OS 内核。

【参考方案1】：

RTOS 并不总是用 C 编写的。通常是这样，但在 ThreadX 中我相信他们使用汇编。

【讨论】：

C 将被编译为汇编，您甚至可以在大多数 C 编译器中使用内联汇编。

【参考方案2】：

因为 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) 非专家可以直观地使用对象来实现概念设计 高层

【参考方案3】：

为 RTOS-es 通常运行的所有硬件提供高度优化的 c 编译器。 您可以相对轻松地 包括非常低级别的优化 在 c 代码中。 许多 c 代码的可用性 有用的低级系统工具 因此可以很容易地合并。

【讨论】：

+1 是您的第二个原因。在编写任何类型的操作系统时，您将不得不时不时地与硬件进行真正的亲密接触。 Java 的设计意图是掩盖真正低级的东西，它表明了。

【参考方案4】：

如果有的话，那是因为指针。在 Java 中，除了基本数据类型之外的所有内容都分配在堆上，任何不是 int 之类的变量都是指针。这不是编写操作系统的好方法，因为它对大多数操作施加了一层间接性，而在操作系统中编写该层可能会杀死你。

操作系统内核是您想要优化和高性能的地方，因为您不知道会在其上运行什么。对于实时操作系统尤其如此，其中半毫秒的延迟可能至关重要。这需要真正熟悉 CPU 和其他硬件，以及编写高度微优化的代码的能力，这些代码将以极好的可预测性执行特定的事情。

因此，C 是构建 RTOS 内核的非常好的工具，而 Java 不是。这并不意味着你不能用 Java 做到这一点，但它会更难，而且可能不会那么成功。

我很好奇你为什么问这个问题。如果您使用的是 RTOS，那么它是用什么编写的并不重要。如果您想破解它，那么它是用什么编写的，但操作系统的概念和实现本身就足够难了学习一门新语言是微不足道的。 （此外，如果您学习操作系统设计和实现，您几乎可以肯定会发现您使用的资源将使用 C 作为教学语言。）

【参考方案5】：

不是“必要”，而是实用得多

作为一种可以使用 Java 的语言，它确实发生了各种古怪的情况。

但一些边缘案例和示范确实更多“证明规则的例外”。

一般来说，Java 是一个用于业务逻辑而非操作系统内核的大型复杂系统。

如果我们还没有 C，Java 可能会朝不同的方向发展，或者朝多个方向发展。

但我们确实有 C，它对于操作系统内核来说几乎是完美的，但对于业务逻辑来说是一个相当大的挑战。

对于内核而言，Java 与 C 一样好的论点与对于应用程序而言 C 与 Java 一样好的论点几乎一样现实。经验，减去一些边缘示例，压倒性地证明了每种语言的优点。

【参考方案6】：

根据定义，RTOS 必须支持确定性调度和执行。一般来说，低中断延迟和直接硬件访问也是一个理想的因素。 Java 中使用的垃圾回收、JIT 编译和字节码执行等技术使这些目标难以实现。

Java 可用于实时系统，但通常在 RTOS 上运行，而不是在其实现中使用。

话虽如此，但建议 RTOS 始终用 C 实现同样不正确。任何系统级语言都适用，包括汇编程序。在大多数情况下，至少内核的某些部分无论如何都会在汇编程序中。 C++ 将是一种合适的语言（很明显，因为它本质上是 C 超集），许多商业 RTOS 在任何情况下都有 C++ 包装器；我习惯性地为 RTOS 开发 C++ 抽象层以支持可移植性。

通常使用 C 的另一个原因是因为 C（通常是 C/C++）编译器通常是第一种并且通常是唯一可用于新架构的语言（汇编程序除外）（现在经常以GNU 编译器实现）。因此，如果您希望能够将您的 RTOS 移植到最广泛的平台，那么使用最普遍的语言是有意义的。

【参考方案7】：

是否需要一直用 C 语言编写 RTOS？

没有。例如，有用 Lisp 或 Smalltalk 编写的 RTOS。

为什么不能用 java 或其他技术进行编码..？？

是什么让你认为它不能？

是因为java中没有指针的概念吗？

不，这是因为有一个神话，操作系统只能用 C 编写。一个神话可以被简单地证明是错误的，但仍然拒绝死亡。

这个神话是如此普遍，以至于想要编写新操作系统的人都不敢尝试 C 以外的任何东西。

【讨论】：

如果证明这么琐碎，一些链接怎么样？

更重要的是，神话在哪里？这个问题的哪些答案声称操作系统只能用 C 编写？

@Jörg：这不是关于编写操作系统，而是编写 RTOS。 RTOS 的全部意义在于它是确定性的。要拥有一个真正确定性的 java，您需要删除很多对 java 有益的东西（即使您使用 Java RTS），这会破坏使用它的目的。如果你编码正确并使用像 JRRT 这样的东西，你可以非常接近，但在编写 RTOS 时你不会像你需要的那样实时。至少现在还没有。

我想我应该指出，我听说过的唯一广泛使用的 Lisp 操作系统是在专门设计的硬件上运行的，没有人告诉我它们是实时的。是否有用 Lisp 或 Smalltalk 编写的实际实时操作系统？

【参考方案8】：

C 是为编写操作系统而设计的，因此有“可移植汇编程序”的常见措辞，因此可以预期它被用于此目的。

如果您想拥有实时 Java，Sun 提供了商业产品。

【参考方案9】：

是否需要一直用 C 语言编写 RTOS？

没有。您也可以在汇编程序、Ada 和其他一些程序中编写 RTOS。

为什么不能用 java 或其他技术编码..？是因为java中没有指针的概念吗？

没有。代码执行时间不可预测。

【参考方案10】：

因为基于 C 语言的 RTOS 广为人知，并且已经使用了数十年。它们的行为在许多特定情况下是可以预测的，您可以找到许多使用这些系统进行开发的专家。

据我所知，没有任何基于 Java 的 RTOS 达到了制造安全关键实时应用程序的公司会采用它的水平。

从技术上讲，没有人反对基于 Java 的 RTOS，但有关该主题的研究、工程和产品尚不成熟。

【参考方案11】：

实时系统也可以用其他语言进行编程。例如，Java 有一个Java RTS System。

与其他答案相反，实时垃圾收集方面的工作量是合理的。但是，这些不会捆绑在您的典型发行版中。

令人担忧的是，其他语言通常具有难以实现确定性和可靠性的特性，例如传统的垃圾收集、JIT、运行时优化等。

【讨论】：

您会注意到 Java RTS 系统必须在 RTOS 之上运行 - 还没有人构建实时裸机 Java 系统。

@notnoop：人们已经这样做了，例如jnode.org和cjos.sourceforge.net/archive

Ajile 系统 (www.ajile.com) 制作实时 Java CPU。他们在裸机硬件上运行 Java。中断响应延迟低于 1 微秒。线程到线程上下文切换花费不到 1 微秒。在 100% cpu 时，最大功耗为 100 毫瓦。性能与 400Mhz 的 Pentium 相当。使用它们的公司不会做广告。对他们来说，这是一种竞争优势。找人做嵌入式 Java 实时，现在这有点困难。我喜欢他们的硬件。它使用起来很有趣，已经为真实的公司解决了现实世界的问题，并且在世界各地都在使用。

最新的 jnode 进度报告日期为：2008 年。四年前发表此评论。从那里有什么发展吗？

【参考方案12】：

Java 中有 Real Time，但它需要操作系统的支持。 见：http://java.sun.com/javase/technologies/realtime/index.jsp

【参考方案13】：

起初，RTOS 不仅仅是用 C 编码的。它们也可以用其他语言编码。然而，用于 RTOS 的语言需要提供确定性的行为。这意味着特定操作的延迟必须始终低于特定时间量。这排除了例如垃圾收集，在大多数实现中它将停止所有线程的执行一段不确定的时间。

【讨论】：

Gosh ...其中大多数曾经在 FORTRAN 和汇编程序中编码。 C RTOS 就像带有 CD 播放器和斗式座椅的“进化”选项。 在 INTeL 硬件上，相当多的实时系统工作是用 PL/M 编写的，您必须将其描述为宏汇编程序高级语言 (3GL)。

【参考方案14】：

像 Java 这样的垃圾收集语言非常不适合实时编程。原因应该很明显。

【讨论】：

有实时垃圾回收这样的东西：ibm.com/developerworks/java/library/j-rtj4/index.html

不是每个问题的答案都很明显吗？

Sun 有 Java 的商业实时版本。

本着答疑解惑的精神，列出原因或许会有所帮助。有各种级别的用户，对某些人来说显而易见的可能对其他人来说并不明显。

@semaj：但在这种情况下，答案显而易见：@Anon 显然从未听说过实时垃圾收集器。

【参考方案15】：

垃圾收集是 Java 不支持实时的重要原因。 JIT 是另一个，但它可以被克服。

一般来说，C 是有效的可移植程序集，可提供非常可预测的运行时性能，这对于可靠的实时执行至关重要。

【讨论】：

Java 确实有一个 RTS 系统，并且在实时垃圾收集方面有一些很好的研究和工作。

@TheManWithNoName：垃圾收集是什么意思？什么是 JIT？

JIT 是“即时编译器”，它极大地改变了代码的运行时特性en.wikipedia.org/wiki/Just-in-time_compilation 垃圾收集是 Java 实现的自动内存清除。

垃圾收集是自动释放未使用的对象 - 这通常有可能暂停正在运行的应用程序（可以减少暂停，但很难完全消除，而不会有内存不足的风险）。 JIT 是即时编译器，它可以根据需要将大量使用的 java 字节码转换为本机代码 - 这显然会极大地改变性能，但它本身需要时间来执行，并且您可能需要强制完成编译以满足开始时的实时目标。

实时垃圾收集器已经存在了几十年。 Java 绝不需要 JIT。事实上，几乎所有现有的 Java 实现中都没有 JIT 编译器。通常，在 JVM 实现中有一个，但是 a) Java 不需要 JVM，b) JVM 也不需要 JIT。

【参考方案16】：

我认为java为此目的最大的问题是自动垃圾收集。这是一个 link 在 java 中创建实时系统。