为什么RTOS仅在c中编码？
是否有必要用C语言编写RTOS？ 为什么不能用java或其他技术编码.. ?? 那是因为java中缺少指针概念吗？
垃圾收集是Java成为实时的重要原因。 JIT是另一个，但它可以克服。
一般而言，C是有效的可移植组件，可提供非常可预测的运行时性能，这对于可靠的实时执行至关重要。
实时系统也可以用其他语言编程。 例如，Java有一个Java RTS系统 。
与其他答案相反，实时垃圾收集的工作量合理。 但是，这些不会捆绑在您的典型分发中。
令人担忧的是，其他语言通常具有难以实现确定性和可靠性的function，例如传统的垃圾收集，JIT，运行时优化等。
起初，RTOS不仅仅用C编码。它们也可以用其他语言编码。 但是，用于RTOS的语言需要提供确定性行为。 这意味着特定操作的延迟必须始终在特定的时间内。 这排除了例如垃圾收集，在大多数实现中，垃圾收集将在不确定的时间内停止所有线程的执行。
因为RTOS开发人员很可能不太了解C ++。
嵌入式系统中的C ++：神话与现实
有些人认为C ++有开销和成本使得它不适合嵌入式系统编程，它缺乏C的控制和简洁，或者虽然它可能适合某些小众应用，但它永远不会取代C作为语言嵌入式系统的选择。
这些看法是错误的。 在编译器和其他工具足够的地方，C ++总是优于C作为嵌入式系统的实现语言。 在完成C所做的一切时，它提供了更多表达，封装，重用的机会，甚至允许在C中不切实际的尺寸和速度改进。
>那么，为什么这些看法仍然存在？ 主要原因是当人们形成他们的观点时，他们对C的了解远远超过C ++。 他们已经阅读了一些书籍，编写了一些代码，并且能够使用C ++的function，但是他们缺乏对引擎盖下发生的事情的了解，熟悉程度允许人们在输入源代码时可视化反汇编，甚至在制定时也是如此。设计。
在嵌入式设计中使用C ++替代C的指南
嵌入式软件应用程序通常用C语言编写。多年来，C ++一直被视为自然的inheritance者，并且已经获得了更大的认可，但其使用量的增长远远低于预期。
有许多的原因。 首先，嵌入式开发人员非常保守，他们更喜欢使用经证实而非新颖的解决方案，如果它没有破坏，就不要修复它“。
还有经验教训。 许多开发人员试图将C ++用于嵌入式应用程序并且失败了。 这种失败有时可能归因于开发工具的缺点，但最常见的是使用“对待台式计算机等嵌入式系统”这一语言的不当使用。
C的局限性尽管C被广泛使用，但它具有局限性，因为它不是为嵌入式应用程序或现在常见的规模项目而设计的。 主要限制包括：
1）C非常强大和灵活，因此可能是危险的。（它具有低水平的能力 – 这对于嵌入式是有用的“但也代表了许多不警惕的陷阱。）
2）程序员需要非常有条理和有纪律
3）程序员需要了解程序在低级别和高级别的行为（大型项目难以维护）
4）程序员需要具备应用程序的专业知识
但是，C ++具有强大的面向对象function，可以帮助解决C的局限：
1）它将非专家的高专业知识区域封装并隐藏在“对象”中; （测试用例将在本系列的第2部分中展示专业知识的封装）。
2）非专家可以直观地使用对象来实现高级概念设计
不是“必要”，但更实用
作为一种语言，可以使用Java，并且实际上发生了各种古怪的案例。
但是，一些边缘案件和示威活动实际上更像是“certificate规则的例外” 。
通常，Java是一个用于业务逻辑而非OS内核的大型系统。
如果我们还没有C ，那么Java可能在不同的方向或多个方向上发展。
但我们确实拥有C，这对于操作系统内核来说几乎是完美的，对业务逻辑来说也是一个挑战。
对于内核而言，Java与C一样好的论点与C对应用程序的Java一样好。 经验，减去一些边缘的例子，绝对certificate了每种语言的好处。
- 针对RTOS通常运行的所有硬件提供高度优化的c编译器。
- 您可以相对轻松地在c代码中包含非常低级别的优化。
- c代码可用于许多有用的低级系统工具，因此可以很容易地合并。
根据定义，RTOS必须支持确定性调度和执行。 通常，低中断延迟和直接硬件访问也是一个理想的因素。 Java中使用的技术（如垃圾收集，JIT编译和字节码执行）使这些目标难以实现。
Java可以在实时系统中使用，但通常它在 RTOS 上运行而不是在其实现中使用。
总而言之，建议RTOS始终用C语言实现同样是不正确的。任何系统级语言都适用，包括汇编程序。 在大多数情况下，至少内核的某些部分在任何情况下都是汇编程序。 C ++是一种合适的语言（很明显，因为它本质上是一个C超集），许多商业RTOS在任何情况下都有C ++包装器; 我习惯性地为RTOS开发C ++抽象层以支持可移植性。
通常使用C的另一个原因是因为C（通常是C / C ++）编译器通常是第一个且通常是新架构可用的唯一语言（汇编器除外）（现在经常以GNU编译器实现的forms） ）。 因此，如果您希望能够将RTOS移植到最广泛的平台，那么使用最普遍的语言是有意义的。
我认为java的最大问题是自动垃圾收集。 这是一个关于在java中创建实时系统的链接 。
因为基于C的RTOS是众所周知的并且已经使用了数十年。 对于许多特定情况，他们的行为是可预测的，您可以找到许多专家来开发这些系统。
我知道没有基于Java的RTOS达到一定程度，以至于制作安全关键实时应用程序的公司会采用它。
从技术上讲，没有针对基于Java的RTOS的争论，但关于该主题的研究，工程和产品尚未成熟。
Java中有实时，但它需要操作系统的支持。 请参阅： http ： //java.sun.com/javase/technologies/realtime/index.jsp
是否有必要用C语言编写RTOS？
不。您也可以在汇编程序，Ada和其他一些代码中编写RTOS代码。
为什么不能用java或其他技术编码.. ?? 那是因为java中缺少指针概念吗？
不可以。代码执行的时间不可预测。
C是为编写操作系统而设计的，因此常用的术语是“便携式汇编程序”，因此可以预期它用于此目的。
如果您想拥有实时Java，Sun可以提供商业服务。
如果有的话，这是因为指针。 在Java中，除了基本数据类型之外的所有内容都在堆上分配，任何不像int变量都是指针。 这不是编写操作系统的好方法，因为它在大多数操作中强加了一层间接，而在操作系统编写中，该层可以杀死你。
操作系统内核是您需要优化和高性能的地方，因为您不知道将在其上运行什么。 对于实时操作系统尤其如此，其中半毫秒延迟可能是至关重要的。 这需要在CPU和其他硬件上变得非常亲密，并且能够编写高度微优化的代码，这些代码将执行具有很强可预测性的特定事物。
出于这个原因，C是构建RTOS内核的非常好的工具，Java不是。 这并不意味着你不能用Java做到这一点，但它会更难，也可能不那么成功。
我很好奇你为什么问这个问题。 如果您正在使用RTOS，那么它的写入并不重要。如果您想要破解它，那么它的内容确实很重要，但操作系统的概念和实现本身就足够了学习一门新语言是微不足道的。 （此外，如果您学习OS设计和实现，您几乎肯定会发现您使用的资源将使用C作为教学语言。）
RTOS并不总是用C语言编写。通常是这样，但在ThreadX中我认为它们使用汇编。
像Java这样的垃圾收集语言非常不适合实时编程。 原因应该是显而易见的。
是否有必要用C语言编写RTOS？
没有。例如，有用Lisp或Smalltalk编写的RTOS。
为什么不能用java或其他技术编码.. ??
是什么让你觉得它不能？
那是因为java中缺少指针概念吗？
不，这是因为有一个神话，即操作系统只能用C编写。这个神话可以被轻易certificate是错误的，但仍然拒绝死亡。
这个神话是如此普遍，以至于那些想要编写新操作系统的人，只是害怕尝试C以外的任何东西。