another bizarre architecture
in [Embedded]
|
From: John Larkin on 2 Feb 2007 15:25 On Fri, 02 Feb 2007 10:31:12 -0700, Jim Thompson <To-Email-Use-The-Envelope-Icon(a)My-Web-Site.com> wrote: >On Fri, 02 Feb 2007 17:16:14 GMT, Vladimir Vassilevsky ><antispam_bogus(a)hotmail.com> wrote: > >> >> >>John Larkin wrote: >> >>>>Look at Airbus fly by wire, _that_ is professional software with >>>>lives at stake. >>> >>> >>> One of my best customers makes jet engines. The engine control >>> computers are mounted under the engine cowling, in the airstream, and >> > the engine fuel runs through the computer before being burned, to >> > moderate the CPU's temperature swing. The programs have no bugs, >> > because they are careful, >> >> >> >>What a bullshit. >> >>If you take a closer look to those systems, you will find the same pile >>of lousy code as everywhere. Well, it is more or less tested so the >>major bugs are unlikely. >>If you *really* know how the car or the aircraft is build, you will >>never drive it or fly by it. >> >> >>> work at the lowest possible levels of >>> abstraction, use no OS, test exhaustively, >> >>:))))) >>They probably don't use the power tools also. >> >> >> and are entirely pragmatic >>> about the consequences of a jet engine failing. >> >>The consequences are excellent: the insurance company pays out the >>compensation of $1e7. >> >>> And most of the >>> "programmers" are actually engineers. >> >>Most of the programmers are the former elephant riders or rice farmers. >> >>VLV >> >> > >Hey, John Larkin! How come you keep attracting the nutcases ?:-) > > ...Jim Thompson Strange. Some people have a powerful vested interest in the premise that good programming is impossible. John
From: John Larkin on 2 Feb 2007 15:26 On Fri, 2 Feb 2007 08:58:06 PST, mojaveg(a)mojaveg.lsan.mdsg-pacwest.com (Everett M. Greene) wrote: >John Larkin <jjlarkin(a)highNOTlandTHIStechnologyPART.com> writes: >[snip] >> Software should be *more* reliable than hardware, since software has >> no inherent failure modes, isn't subject to temperature changes, power >> glitches, parts variability or EMI, and is precisely reproducable >> times a million copies... no solder joints, no part tolerances. Yet >> it's the hardware that's usually most reliable. Software is buggy >> because of miserable programming methodologies and practices. Mine's >> not. > >While programming is not subject to mechanical failures, >it is susceptible to other kinds of failures including >failures of the underlying hardware. Then add the >usual expectation that the programming should be able >to compensate for if not recover from hardware problems >and you've elevated programming reliability to a wholly >different level. But it's seldom the CPU or the memory that fails; it's the software itself. Memories don't leak, but memory allocators/deallocators do. John
From: Jan Panteltje on 2 Feb 2007 15:50 On a sunny day (Fri, 02 Feb 2007 12:26:59 -0800) it happened John Larkin <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote in <9i77s2p5rd1df47h7b2cakjgsv5aji242r(a)4ax.com>: > >But it's seldom the CPU or the memory that fails; it's the software >itself. Memories don't leak, but memory allocators/deallocators do. > >John John, its not fair. Its late here, but anyways.... Software does not 'start failing' all of the sudden, unless data was damaged (the executable), if you started with good software. Same for hardware, but hardware _WILL_ fail over time. Be it electrolytic caps, overloads, or whatever. I must say if you can write perfect software that is very good. I _do_ put restriction on what I am prepared to do, this especially in view of 'attacks' (as via the internet), 'fixed' jpeg or movies, what not (often buffer overflow exploits). I do not at this time design for life support systems so I feel safe. Nevertheless, unlike Vladimir, I try to write correct code, and some lively discussion on the issue of headers and structures on 32 and 64 bit machines happened recently in comp.os.linux.apps, that caused me to re-write some of my code (although it worked OK). The perfect portable code likely does not exist anyways. In the case of the airplane, I do not know what it did you wrote, but some systems are more complicated then a simple controller and the chances of something going wrong are then bigger, so maybe 3 systems are used with an arbiter.. Especially in the case of airplanes or space, a cosmic ray can cause your hardware to do unexpected things (and the software), so triple redundancy was for example already in the Concorde. So... and now with glass cockpits (all TV screens) I would expect to see a lot of these triple systems... Arbiter is in itself some fascinating thing.
From: Vladimir Vassilevsky on 2 Feb 2007 15:54 John Larkin wrote: > > Strange. Some people have a powerful vested interest in the premise > that good programming is impossible. It is not impossible. It is just not worthy in many cases. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
From: jasen on 2 Feb 2007 14:17
["Followup-To:" header set to sci.electronics.design.] On 2007-02-02, Jan Panteltje <pNaonStpealmtje(a)yahoo.com> wrote: > On a sunny day (Thu, 01 Feb 2007 21:24:37 GMT) it happened Vladimir > Vassilevsky <antispam_bogus(a)hotmail.com> wrote in ><pUswh.15243$ji1.10317(a)newssvr12.news.prodigy.net>: > FILE *fptr; > > fptr = fopen("filename", "r"); > > fread( fptr...) > BANG if file did not exist! > It's easy to post bad code, how would you fix it? >>> The good thing he did was check for divide by zero. >> >>Only the amateurs check the floating point for == or !=. > > You must be programming for Microsoft :-( seriously, checking for equal to zero is pointless, The number could be so close to zero that it would have pracctically the same result as dividing by zero (the only difference is you get "infinite" as a result instead of "not a number") double d = 1.2 - 0.4 - 0.4 - 0.4; d is a small number, but, quite possibly, not 0. Bye. Jasen |