c - 为什么对嵌入式系统使用低级语言或接近它( C )而不是高级语言,当所有语言都被编译为机器代码时?

标签 c embedded

我已经搜索过,但找不到明确的答案。如果我们在计算机(功能强大)中编译代码,那么我们只是将机器指令发送到嵌入式设备中的内存。根据我的理解,如果我们使用任何一种语言,这不会有什么不同,因为最终,我们将只向嵌入式设备发送机器代码,代码编译是昂贵的阶段,已经由强大的功能完成机器!

为什么要使用像 C 这样的语言?为什么不是Java?我们在最后发送机器码。

最佳答案

答案部分在于运行时要求和平台提供的语言期望:C 的运行时大小是最小的 - 它需要一个堆栈,这就是能够开始运行代码的地方。对于兼容的实现,静态数据初始化是必需的,但您可以在没有它的情况下运行代码 - 初始化本身甚至可以用 C 编写,甚至堆和标准库初始化都是可选的,就像库的存在一样。它不需要操作系统依赖性、解释器和虚拟机。

大多数其他语言需要更多的运行时支持,这通常由操作系统、运行时库或虚拟机提供。要“独立”运行,这些语言需要“内置”支持,因此会更大——以至于在许多情况下,您也可以部署带有操作系统和/或 JVM 的系统无论如何。

当然,特定语言适合嵌入式系统还有其他原因,例如硬件级访问、性能和确定性行为。

虽然运行时环境和/或操作系统的问题是您在小型嵌入式系统中很少看到高级语言的主要原因,但这绝不是闻所未闻的。 .Net Micro Framework例如允许在嵌入式系统中使用 C#,并且有许多 embedded JVM实现,当然还有 Linux 发行版被广泛嵌入,使得语言选择几乎不受限制。 .Net Micro 运行在有限数量的处理器架构上,需要相当大的内存(>256kb),JVM 实现可能有类似的要求。 Linux 不会在低于 16Mb ROM/4Mb RAM 的情况下启动。两者都不是特别适合具有微秒级截止日期的硬实时应用程序。

C 在 8 位、16 位、32 位和 64 位平台上或多或少地普遍存在,并且从第一天起通常可用于任何架构,而对其他语言(至少 32 位平台上的 C++ 除外)的支持可能是可变且不完整,并且可能仅在更成熟或广泛使用的平台上可用。

从开发人员的角度来看,一个重要的考虑因素也是针对目标平台和语言的交叉编译工具的可用性。因此,这是一个良性循环,开发人员选择 C(或越来越多地选择 C++),因为这是最广泛使用的工具,而工具/芯片供应商提供 C 和 C++ 工具链,因为这是开发人员的需求。再加上库、开源代码、调试器、RTOS 等形式的第三方支持,选择一种几乎没有任何支持的语言将是勇敢(或愚蠢)的开发人员。受此影响的不仅仅是高级语言。我曾经参与过一个用 Forth 编程的项目——一种比 C 更底层的语言——那是一次孤独的经历,虽然有这种语言的热情拥护者,但坦率地说,他们有点疯狂地偏爱语言传播而不是商业上的成功。简而言之,C 已达到临界质量接受度并且很难被移除。 C++ 受益于与 C 的广泛互操作性和类似的最低运行时要求,以及通常支持这两种语言的工具链。因此,采用 C++ 的唯一障碍主要是开发人员的惯性,以及在某种程度上在 8 位和 16 位平台上的可用性。

关于c - 为什么对嵌入式系统使用低级语言或接近它( C )而不是高级语言,当所有语言都被编译为机器代码时?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/36245710/

相关文章:

c - 过滤数组的有效方法是什么

c++ - C和C++中带有序列点和UB的差异

c - Atmel 处理器已复位,但 MCUSR 中未指示复位源

c - Wiznet W5100 拔出电缆检测

将 vim ctags <C-]> 和 <C-T> 键映射复制到 <C-Q> 和 <C-A>

c - 管道 C 上的多维数组

c - 指向 C 中 const 字符串的指针

linux - 内核中 8 字节对齐的空闲连续页列表

c - 无优化 (-O0) 会导致嵌入式 MCU 崩溃

c - 如何解决 C 代码的 MISRA C :2012 Rule 13. 2 和 13.3?