> Indeed, if memory serves (it's been a while since I read about this)...
> The fly-by-wire flight software for the Saab Gripen (a lightweight
> fighter) went a step further. It disallowed both subroutine calls and
> backward branches, except for the one at the bottom of the main loop.
> Control flow went forward only. Sometimes one piece of code had to leave
> a note for a later piece telling it what to do, but this worked out well
> for testing: all data was allocated statically, and monitoring those
> variables gave a clear picture of most everything the software was doing.
> The software did only the bare essentials, and of course, they were
> serious about thorough ground testing.
> No bug has ever been found in the "released for flight" versions of that code.
You know I work with embedded developers doing C for microcontrollers for battery management systems, me being not familiar at all with that kind of code I found highly fascinating how there wasn't a single case of manually allocated memory anywhere in this huge codebase, everything was statically allocated. Almost no pointers around to be seen, in C code nonetheless.
So different from how I coded C back when I was doing (non-embedded) C development. The downsides of course was that everything had to go against a (very, very small) RAM budget, we once asked to have UUIDs in the system for better cloud integration and that was a no-go (they didn't even _support_ strings)
Another interesting thing was that all variables (and I mean ALL) were global, so even the stack for function calls was very small
While I don't contest the story about software bugs, the Gripen airplane had pretty bad PR for quite some time due to 2 (3 depending on how you count) high-profile crashes. It is fun to see it mentioned in other contexts.
> The fly-by-wire flight software for the Saab Gripen (a lightweight
> fighter) went a step further. It disallowed both subroutine calls and
> backward branches, except for the one at the bottom of the main loop.
> Control flow went forward only. Sometimes one piece of code had to leave
> a note for a later piece telling it what to do, but this worked out well
> for testing: all data was allocated statically, and monitoring those
> variables gave a clear picture of most everything the software was doing.
> The software did only the bare essentials, and of course, they were
> serious about thorough ground testing.
> No bug has ever been found in the "released for flight" versions of that code.
You know I work with embedded developers doing C for microcontrollers for battery management systems, me being not familiar at all with that kind of code I found highly fascinating how there wasn't a single case of manually allocated memory anywhere in this huge codebase, everything was statically allocated. Almost no pointers around to be seen, in C code nonetheless.
So different from how I coded C back when I was doing (non-embedded) C development. The downsides of course was that everything had to go against a (very, very small) RAM budget, we once asked to have UUIDs in the system for better cloud integration and that was a no-go (they didn't even _support_ strings)
Another interesting thing was that all variables (and I mean ALL) were global, so even the stack for function calls was very small