机载系统有"DO-178B"A级和B级认证。它是否禁止使用优化编译器?
。有些编译器会重新排序指令以获得更好的性能。DO-178B是否有效?A或lev。B禁止重新排序?
大多数现代CPU在硬件中都有这样的重排序功能。它们可以在DO-178B级内使用吗?一个软件/硬件系统?
首先，重要的是:对于这类问题，如果答案很重要，您需要从有能力提供答案的人那里获得正式的专业意见，或者与您的认证机构讨论这个问题。你在这里得到的任何答复都不可靠。
话虽如此，我会假设你是出于好奇而问，不会以任何有意义的方式依赖于答案，我会尝试以这种方式回答。我不是专业人士，这不是专业建议。我能在网上快速搜索到的最准确的文档是关于相关主题的FAA指南文件:http://www.faa.gov/aircraft/air_cert/design_approvals/air_software/cast/cast_papers/media/cast-12.pdf。本文描述了必须对生成的目标代码而不是源代码进行验证的条件。特别是，它给出了许多即使在非优化代码中也会出现的例子——自动变量初始化和异常处理就是两个例子。关于编译器优化，它指出:
编译器优化是DO-178B/ED-12B第4.4.2a节中提到的另一个领域。这涉及到分析性的确定，即优化特性不会损害测试用例演示基于需求的测试和与软件级别一致的结构覆盖的能力。这是与第4.4.2b节所述的可追溯性和附加验证问题分开的问题。这超出了本文的范围。
我手边没有do - 178b的副本来阅读第4.4.2a节，但我要注意(a)有处理其他情况的过程，其中目标代码不以一对一的方式对应于源代码，并且(b)这非常强烈地暗示编译器优化是讨论而不是完全禁止的。
从那篇论文中的许多讨论中也可以很清楚地看出，"我们不能在源代码和目标代码之间跟踪东西"的答案是以某种方式验证目标代码——换句话说，除了禁止这样的事情之外，还有一个解决方案。
因此，我可以得出结论，至少必须允许一些编译器优化。
特别是，你所描述的那种重新排序是相当可追溯的，而且在我看来几乎可以肯定它是被允许的。
DO-178B不是绝对的，可以解释。如果你关闭优化，就没有问题，也没有什么可以解释的。通过坚持最明显的解释，您可以避免以后不得不向认证机构推销您的解释，并避免让自己面对有关您如何做事情的问题。
当你优化你的代码时，很难做到a级所需的从源到指令的可追溯性。此外，如果你使用do - 178b，从你的软件中获得额外的5%并不是你最关心的。轻松完成所有必需的认证步骤应该是您最关心的问题，因为这将占用您所有的时间。
你问题的硬件部分很有趣。对于软件优化代码不只是重新排序，它也改变了。但是对于硬件来说，代码并没有改变以获得更高的速度，只是改变了执行顺序。我不得不四处打听，以获得更多关于这个想法的信息。
我对do - 178b只有肤浅的了解(我不是每天使用它，但我为使用它的人构建工具)。
标准非常重视可追溯性。高级需求被分解为低级需求，低级需求由源代码实现，由编译器编译。在每一个步骤中，必须能够根据前一步产生的规范来证明所做的工作。
对于编译器来说，这意味着必须能够读取程序集并跟踪一条特定的指令，直到生成该指令的源代码语句。
所以，简而言之，是的，我认为这阻止了大多数优化。
关于这个软件运行的硬件，它是不同的验证(但我猜同样严格)。相关标准是当时的do -254，我对此一无所知
通过优化，您需要在对象汇编语言级别验证生成的代码。有一些用于嵌入式实时多任务处理的编译器套件和库已经在其他项目中验证过了，这让您可以放心地再次验证它们——但是您仍然需要验证应用程序中使用的代码。
为了避免延迟和不得不解释事情，只需关闭优化和缓存。这使得代码具有确定性。如果可能的话，尽量不要使用GCC，使用合格的编译器，如IAR或DDCI或Irvine编译器或其他东西。而不是试图用一个花哨的锤子敲螺丝，用一个螺丝刀工作的螺丝。因为当一架载有200人的飞机坠毁时，机上有父母和孩子，他们发现是编译器重新排序了代码，导致了失败，你会希望你只有正确的螺丝刀。