Programming the F35

S

sublight

Guest
This is pretty awful. http://www2.research.att.com/~bs/JSF-AV-rules.pdf

They try pretty hard to mitigate the pitfalls of C++, but its a complete nightmare to hire more programmers just to go look at another set of programmers work. In the real world you address bugs by having millions of users run your Doom3 or Photoshop to find them. Not so much when you have a fighter plane that has to work right the first time.

They should have gone straight C or just done the systems in assembly.
 
You should go UP the language ladder, not DOWN. True high-level languages would be better than something like C or assembly (functional languages can be considered true high-level, Ada language works for high-level).

C++ is not a high-level language, it's just a psuedo-highlevel extension to C
 
You're going to have an abstraction penalty with high level languages. F35 has a LOT of functionality and likely no room for a computational performance hit.
 
If more computational capacity is needed, the F-35 has an unused ICP bay in the rear of the F-35 that they can use for expansion.
 
sublight said:
You're going to have an abstraction penalty with high level languages. F35 has a LOT of functionality and likely no room for a computational performance hit.
That's not entirely true. Ada proves that an efficient compiler can provide code fast enough. If you need more functionality I think it's better to split it into several processors or increase the processor speed, rather than switch to a lower-level language.

Only most critical functions which do not have any high-level elements should be programmed in a low-level language - such as memory management, virtual machine (if applies), etc.
 
OT: high level languages...

Hopefully they'll do better in C++ than I'm managing with the rudiments of Python 2.7x-- Just when I think I've comprehended a concept, a quirk comes along which leaves me gibbering...
 
Black Phoenix said:
sublight said:
You're going to have an abstraction penalty with high level languages. F35 has a LOT of functionality and likely no room for a computational performance hit.
That's not entirely true. Ada proves that an efficient compiler can provide code fast enough. If you need more functionality I think it's better to split it into several processors or increase the processor speed, rather than switch to a lower-level language.

Only most critical functions which do not have any high-level elements should be programmed in a low-level language - such as memory management, virtual machine (if applies), etc.
This is a fighter plane. It's got a LOT subsystems that need to talk to each other in realtime where just a few milliseconds of latency might mean the difference between hitting a bogey and taking a missile up the tailpipe. You dont do complex realtime systems with a high level language.
 
sublight said:
Black Phoenix said:
sublight said:
You're going to have an abstraction penalty with high level languages. F35 has a LOT of functionality and likely no room for a computational performance hit.
That's not entirely true. Ada proves that an efficient compiler can provide code fast enough. If you need more functionality I think it's better to split it into several processors or increase the processor speed, rather than switch to a lower-level language.

Only most critical functions which do not have any high-level elements should be programmed in a low-level language - such as memory management, virtual machine (if applies), etc.
This is a fighter plane. It's got a LOT subsystems that need to talk to each other in realtime where just a few milliseconds of latency might mean the difference between hitting a bogey and taking a missile up the tailpipe. You dont do complex realtime systems with a high level language.

Just FYI the F-15E has about the equivalent of a 386. Even a low-end video card would blow the doors off it computation-wise. On the other hand I imagine getting the latency out of the EO DAS is going to take some horsepower.
 
Not only is it going to take some horsepower, its going to take some herculean effort to get the bugs out. What the team ought to do is make a free F35 video game using the real code for the subsystems (or at least the unclassified parts) so they can rack up millions of man hour testing reeeeeeally really quickly..... DARPA did something similar with a sub hunter game a while back, but there is no telling if it had real systems code in it...

http://archive.darpa.mil/actuv/
 
sublight said:
This is pretty awful. http://www2.research.att.com/~bs/JSF-AV-rules.pdf

They try pretty hard to mitigate the pitfalls of C++, but its a complete nightmare to hire more programmers just to go look at another set of programmers work. In the real world you address bugs by having millions of users run your Doom3 or Photoshop to find them. Not so much when you have a fighter plane that has to work right the first time.

They should have gone straight C or just done the systems in assembly.

What about that set of rules is awful? Enforcing a consistent coding style is essential when you have so many people working on the code.

For critical applications like this, writing the software is just part of the process. Bugs are inevitable, but there are ways to minimize them. This starts with an exhaustive set of design specs before you start writing code. Coding has to be followed up by testing, the more exhaustive the better. The rules help make the software testable.
 
in the end we will see something like this ...

http://www.youtube.com/watch?v=x3tedlWs1XY

What the team ought to do is make a free F35 video game using the real code for the subsystems (or at least the unclassified parts) so they can rack up millions of man hour testing reeeeeeally really quickly...
that's what she say'd

it is very interesting to learn that f-15 have 386 i thought it was with i8080
what about this guy
http://www.mcst.ru/elbrus_2c_111101.shtml

ps wrong video :D
 
sublight said:
This is pretty awful. http://www2.research.att.com/~bs/JSF-AV-rules.pdf

They try pretty hard to mitigate the pitfalls of C++, but its a complete nightmare to hire more programmers just to go look at another set of programmers work. In the real world you address bugs by having millions of users run your Doom3 or Photoshop to find them. Not so much when you have a fighter plane that has to work right the first time.

They should have gone straight C or just done the systems in assembly.

That's not true at all. In the real world, you address bugs through *testing*. Not with users, with automation. You test every possible path through the code, and your engineers do their best to minimize those paths to reduce code complexity. Computers are pretty good at repetitive tasks, which makes them pretty good for testing. I can analyze every possible path through the code, and magically create tests that exercise all of these paths, in every possible combination. I can measure the complexity of the code, and not allow an engineer to commit code that exceeds a given threshold. I can also not allow code that does not have a full set of tests executing every one of those paths.

Strangely, these practices produce robust software.

MISRA's guidelines are a good explanation of these concepts:
http://www.misra.org.uk/Publications/tabid/57/Default.aspx#label-dvg
(MISRA-C 2004 is most relevant).
 
quellish said:
.. In the real world, you address bugs through *testing*. Not with users, with automation. You test every possible path through the code, and your engineers do their best to minimize those paths to reduce code complexity. Computers are pretty good at repetitive tasks, which makes them pretty good for testing. I can analyze every possible path through the code, and magically create tests that exercise all of these paths, in every possible combination. I can measure the complexity of the code, and not allow an engineer to commit code that exceeds a given threshold. I can also not allow code that does not have a full set of tests executing every one of those paths.
Meanwhile in the real world, Microsoft, the biggest software developer on the planet bar none, cannot completely test every code path. Now you're going to tell me that the subcontractors on this project are going to test every code path and every variation of code path interaction with the other systems code paths on their comparatively miniscule budget? I don't think so.
 
Windows, when left to it's own devices, runs pretty well.

The problem comes when un-controlled (read 3rd party) software is loaded. This is the main reason why the DoD will not give anyone the codes or allow any extra software to be loaded..
 
sublight said:
Meanwhile in the real world, Microsoft, the biggest software developer on the planet bar none, cannot completely test every code path.

You're right when it comes to Windows, which has to interact with tens of thousands of pieces of hardware and millions of application programs.

But on an environment that's tightly controlled? Of course you can do exhaustive testing.
 
sublight said:
Meanwhile in the real world, Microsoft, the biggest software developer on the planet bar none, cannot completely test every code path. Now you're going to tell me that the subcontractors on this project are going to test every code path and every variation of code path interaction with the other systems code paths on their comparatively miniscule budget? I don't think so.

Boring repetitive work is something that computers are fairly good at. Microsoft is certainly *able* to test every path through their code. Wether they decide to do so is a business decision on their part.

There are finite inputs and finite paths through the code. If your implementation is impractical to test you have already lost the battle.
 
With an eye to the future?


Lockheed Martin bought a D-wave quantum computer with the expressed purpose of "use the new purchase to aid identification of bugs in products that are complex combinations of software and hardware".
http://www.technologyreview.com/news/424163/tapping-quantum-effects-for-software-that-learns/


of course there may well be other applications that they would like to investigate ;)


USC-Lockheed Martin Quantum Computing Center have recently upgraded to a new 512-qubit "Vesuvius" chip.
http://www.rdmag.com/news/2013/07/research-finds-prototype-quantum-chip-operates-hoped
 

Similar threads

Back
Top Bottom