> ...I think something has been lost here. You seem to be implying that > writing "fast" code does not matter for "embedded" code, because it runs > against a fixed clock.
The thing being lost is the difference between code that you think is fast and code that you have *proven* is fast. the FAA requires that life critical avionics be *proven* to be fast *and* accurate, *no matter what*. And while desktop code jockeys will throw a few test cases at their code (top down testing) and decide that it is "fast enough", the FAA won't let that approach fly. Proving a system is fast and accurate no matter what inputs it sees isn't easy. If you can prove the low level blocks behave a certain way no matter what input they get, and if you can prove that putting those blocks together doesn't create any new behaviour, then you have essentially proven your system. If your blocks behave a certain way in standalone, but start behaving differently depending on how the rest of the system is behaving, then you really haven't proven anything. Most FAA requirements prohibit stuff that causes the system to behave differently depending on how the rest of the system is behaving. Malloc being a good example. You can't prove that malloc will always work no matter what because you don't know what your system might do with malloc. Even if you get malloc to work perfectly, how do you *prove* that the system won't try to allocate more memory than exists? You can't. What you're doing is you're telling me that you think using exceptions will be faster than using other control structures. And maybe you can provide a case where the real objective measures show that it is faster. But you haven't *proven* it will be fast and accurate *no matter what*. _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
