11 ms·

It is very interesting because directly states that for C++ to be as efficient you need to have the optimizer on. Now for most scenarios that makes perfect sens

It is very interesting because directly states that for C++ to be as efficient you need to have the optimizer on. Now for most scenarios that makes perfect sense but for aerospace we need to be able to match the code directly between the assembly and C code. Without this it is incredibly difficult to do full verification.

fooker 8y ago
>Without this it is incredibly difficult to do full verification. You can verify the optimizations on their own. Example: https://www.cs.utah.edu/~regehr/papers/pldi15.pdf https://www.cs.utah.edu/~regehr/papers/pldi15.pdf
- gmueckl 8y ago
  In the framework of safety-critical software correctness of the compiler is a prerequisite, but not seen as sufficient to prove the correctness of the actual translation.
  - fooker 8y ago
    Why?
    - gmueckl 8y ago
      Because the compiler is only correct if its execution environment is also correct. This cannot be guaranteed. And also because the relevant standards say so.
      - fooker 8y ago
        Can you point me to these standards? I do research in this field and it would be helpful to refer to such standards in papers.
        gmueckl 8y ago
        For traceability you would need to look at Do-178C. I am currently not aware that ISO 61508 (general functional safety) and ISO 26262 (automotive functional safety) require traceability between source code and executable machine code. All standards specify different levels of safety. Lower levels come with fewer requirements and are easier to implement, but are recognized as less reliable and therefore limited to less critical applications.
klmr 8y ago
That’s true but for the most part such optimisations happen very predictably (and are extensively verified when applicable). This isn’t a case of writing some very abstract code and hoping that the compiler will sort it. Rather, you use abstractions that have been carefully designed and implemented (probably by you) to result in predictable machine code (another comment links to a good example of this by James Turner; the key here is that this example is obviously chosen for illustration purposes, but can be generalised). C++ does not relieve you of the responsibility to understand the abstractions you’re using, but it does make it possible to write such abstractions; for example, writing an iterator over a complex container type that, when used with a range-for loop, compiles down to a single inc/cmp/jne (this is in fact what a range-for loop over a `std::vector` does). Optimisations in C++ (those that are relevant here, anyway) are something that need to be relied on to write efficient code, but they also can be relied on.
LordHog 8y ago
In years past I worked for a couple different aerospace companies. Optimization for the tools had to be turned off, period! As sbradford26 mentioned, this was need for verification, especially for Software Verification Cases & Procedures document (SVCP). This is especially important for Level A. I worked on Level B LRUs. The projects steered clear of C++ given there is a lot of code generated that is not easily trace to the written source if using C++ features (constructors and polymorphism as a couple examples). Yes, there are companies out there that do use C++ for aerospace, but I never worked at a company that did. The project also used in-house schedulers/executives. Boeing highly suggested to that company I was at, early 2000's, not to use a commercial RTOS (even a verified ones from companies like Green Hills or VxWorks). All companies developed a schedule/executive that suited the needs of the projects, but they were all very similar in the end. I also worked at a company that developed solutions for industrial controls and they follow a similar path to DO-178B/C guidelines. The company followed IEC 61508 which had a very similar flow to DO-178B. All products, except one that was not safety critical, used C and used an in-house scheduler/executive also. I took this from https://www.certon.com/do-178-development-certification/ https://www.certon.com/do-178-development-certification/: "Source to Object Code Trace Analysis (Level A Only) The compiler converts the Source Code into assembly object code before it is compatible with the target computer. For DAL A software, it is required to provide assurance that all assembly object code generated by the compiler is traceable to the source code. Any assembly object code that is not traceable directly to the source code requires additional verification to be performed in order to provide safety assurance and the absence of unintended behavior." Certification Authorities Software Team (CAST) (a bit dated and I didn't try to find if a newer version exist) https://www.faa.gov/aircraft/air_cert/design_approvals/air_software/cast/cast_papers/media/cast-12.pdf https://www.faa.gov/aircraft/air_cert/design_approvals/air_s... Edit: For most projects, at least the ones I was on, 50% of the budget was allocated for validation/verification. Thus, reducing the additional work to verify code that was not directly related to source is always desired. One prime reason not to use C++.

fooker 8y ago

>Without this it is incredibly difficult to do full verification. You can verify the optimizations on their own. Example: https://www.cs.utah.edu/~regehr/papers/pldi15.pdf https://www.cs.utah.edu/~regehr/papers/pldi15.pdf

gmueckl 8y ago
In the framework of safety-critical software correctness of the compiler is a prerequisite, but not seen as sufficient to prove the correctness of the actual translation.
- fooker 8y ago
  Why?
  - gmueckl 8y ago
    Because the compiler is only correct if its execution environment is also correct. This cannot be guaranteed. And also because the relevant standards say so.
    - fooker 8y ago
      Can you point me to these standards? I do research in this field and it would be helpful to refer to such standards in papers.
      - gmueckl 8y ago
        For traceability you would need to look at Do-178C. I am currently not aware that ISO 61508 (general functional safety) and ISO 26262 (automotive functional safety) require traceability between source code and executable machine code. All standards specify different levels of safety. Lower levels come with fewer requirements and are easier to implement, but are recognized as less reliable and therefore limited to less critical applications.

klmr 8y ago

That’s true but for the most part such optimisations happen very predictably (and are extensively verified when applicable). This isn’t a case of writing some very abstract code and hoping that the compiler will sort it. Rather, you use abstractions that have been carefully designed and implemented (probably by you) to result in predictable machine code (another comment links to a good example of this by James Turner; the key here is that this example is obviously chosen for illustration purposes, but can be generalised). C++ does not relieve you of the responsibility to understand the abstractions you’re using, but it does make it possible to write such abstractions; for example, writing an iterator over a complex container type that, when used with a range-for loop, compiles down to a single inc/cmp/jne (this is in fact what a range-for loop over a `std::vector` does). Optimisations in C++ (those that are relevant here, anyway) are something that need to be relied on to write efficient code, but they also can be relied on.

LordHog 8y ago

In years past I worked for a couple different aerospace companies. Optimization for the tools had to be turned off, period! As sbradford26 mentioned, this was need for verification, especially for Software Verification Cases & Procedures document (SVCP). This is especially important for Level A. I worked on Level B LRUs. The projects steered clear of C++ given there is a lot of code generated that is not easily trace to the written source if using C++ features (constructors and polymorphism as a couple examples). Yes, there are companies out there that do use C++ for aerospace, but I never worked at a company that did. The project also used in-house schedulers/executives. Boeing highly suggested to that company I was at, early 2000's, not to use a commercial RTOS (even a verified ones from companies like Green Hills or VxWorks). All companies developed a schedule/executive that suited the needs of the projects, but they were all very similar in the end. I also worked at a company that developed solutions for industrial controls and they follow a similar path to DO-178B/C guidelines. The company followed IEC 61508 which had a very similar flow to DO-178B. All products, except one that was not safety critical, used C and used an in-house scheduler/executive also. I took this from https://www.certon.com/do-178-development-certification/ https://www.certon.com/do-178-development-certification/: "Source to Object Code Trace Analysis (Level A Only) The compiler converts the Source Code into assembly object code before it is compatible with the target computer. For DAL A software, it is required to provide assurance that all assembly object code generated by the compiler is traceable to the source code. Any assembly object code that is not traceable directly to the source code requires additional verification to be performed in order to provide safety assurance and the absence of unintended behavior." Certification Authorities Software Team (CAST) (a bit dated and I didn't try to find if a newer version exist) https://www.faa.gov/aircraft/air_cert/design_approvals/air_software/cast/cast_papers/media/cast-12.pdf https://www.faa.gov/aircraft/air_cert/design_approvals/air_s... Edit: For most projects, at least the ones I was on, 50% of the budget was allocated for validation/verification. Thus, reducing the additional work to verify code that was not directly related to source is always desired. One prime reason not to use C++.