• Hi Guest! Forum rules have been updated. All users please read here.

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.
 

Black Phoenix

ACCESS: Restricted
Joined
Jun 5, 2011
Messages
4
Reaction score
0
Website
brain.wireos.com
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
 
S

sublight

Guest
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.
 

SpudmanWP

ACCESS: Top Secret
Senior Member
Joined
Nov 10, 2008
Messages
1,072
Reaction score
42
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.
 

Black Phoenix

ACCESS: Restricted
Joined
Jun 5, 2011
Messages
4
Reaction score
0
Website
brain.wireos.com
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.
 

Nik

ACCESS: Secret
Joined
Jul 15, 2009
Messages
415
Reaction score
36
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...
 
S

sublight

Guest
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.
 

sferrin

ACCESS: USAP
Senior Member
Joined
Jun 3, 2011
Messages
13,568
Reaction score
1,585
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.
 
S

sublight

Guest
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/
 

Hobbes

ACCESS: Top Secret
Senior Member
Joined
May 9, 2008
Messages
900
Reaction score
265
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.
 

piko1

< LFM Cow Level >
Joined
May 20, 2009
Messages
143
Reaction score
4
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
 

quellish

I am not actually here.
Senior Member
Joined
Aug 6, 2007
Messages
2,174
Reaction score
203
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).
 
S

sublight

Guest
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.
 

SpudmanWP

ACCESS: Top Secret
Senior Member
Joined
Nov 10, 2008
Messages
1,072
Reaction score
42
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..
 

Hobbes

ACCESS: Top Secret
Senior Member
Joined
May 9, 2008
Messages
900
Reaction score
265
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.
 

quellish

I am not actually here.
Senior Member
Joined
Aug 6, 2007
Messages
2,174
Reaction score
203
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.
 

Mat Parry

ACCESS: Secret
Joined
Jan 25, 2011
Messages
417
Reaction score
8
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

Top