another bizarre architecture

[Vladimir Vassilevsky]

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

 

[Jim Thompson]

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.



))))
They probably don't use the power tools also.


and are entirely pragmatic

The consequences are excellent: the insurance company pays out the
compensation of $1e7.


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

 

[CBFalconer]

John Larkin wrote:
.... snip ...

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.

The code may or may not be lousy, in terms of clarity and
maintainability. However, it will not be buggy. You are obviously
unfamiliar with what it takes to get instrumentation certified for
airworthiness. The specifications may have been foolish (i.e. the
Airbus fiasco).

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

 

[jasen]

What a shamefull nonportable, unsafe and murky piece of code.

at least it's C.

This is a way to go:

not in C it's not.

Bye.
Jasen

 

[John Devereux]

If your vc system tells you that two subroutine sources differ, what
do you do? It certainly can't tell you *why* they differ, or how they
might behave differently.

Yes it can. The source files contains comments describing them. A diff
performed on two copies of the library will show exactly the
differences in the comments, as well as in the code.

For that, you must either read the comments
and revision notes (lots of luck finding them!) or compare the code
character-by-character and try to figure out what's going on. Or just
use the latest one, on the assumption that any bugs aren't your fault.

Comments are in the source file.

Now, what do you do when 12 versions differ?

You can run a "diff" command on the whole library, or on any subset
thereof, to show all the differences between any version and any
other. The Changelog will also contain comments saying what changed
and why.

Yes, comments are nasty things.

Of course I comment the source code - I was just making the point that
you don't always want some "version" number written as a comment in
the C source file. There can be better ways to handle revision control
than typing a number into each source file.

 

[Rich Grise]

Deadlines. That's another reason for the software to be the far from
perfect.

So, you will actually release software that you know is buggy, or that
you haven't tested, because of some schedule? Please tell me who you
work for, so I can be sure to never buy their stuff.
[/QUOTE]

Apparently so. Did you miss the part where he expressed his desire to
be a member of the MS crew?

Given his post, I'd sure never hire the guy. "However not checking the
return code is the very common mistake. The exception mechanism was
invented to prevent this sort of mistakes."

No, Vladimir. Learning how to program properly was invented to prevent
this sort of mistakes[SIC]. "Exceptions" just add another level of bloat
to protect scriptkiddies from their ignorance.

And who's to say the guy who wrote the exception routines wasn't just
as sloppy of a "programmer" as the idiot who's depending on the machine
to do his thinking for him?

Thanks,
Rich

 

[jasen]

There is only one language: C++. The so called C is the malformed
realization of C++, where you have to do classes by hand.


It is better to stay on the earth rather then fall on somebody's head.
Masking the errors is the worst practice.


Come on, get real. Nobody bothers about checking the return value.


Only the amateurs check the floating point for == or !=.

divide by a too-small or zero and you'll get some sort of
infinite or not-a-number from the divide,

so, just divide and check the result using isfinite or isnormal().
depending on the result you're expecting.


Bye.
Jasen

 

[Rich Grise]

It's made on some older fabs that they might prefer to retire.

What they really ought to do is port it to a modern CMOS line, cut the
die size by 4:1 or so, and run it at 100 MHz!

At twelve to fifteen bucks a pop, it'd almost be worth plopping a core
into a mongo CPLD ;-)

Cheers!
Rich

 

[jasen]

["Followup-To:" header set to sci.electronics.design.]

On a sunny day (Thu, 01 Feb 2007 21:24:37 GMT) it happened Vladimir
<[email protected]>:

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?

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

 

[Nico Coesel]

This looks really weird to me...

http://www.maxim-ic.com/appnotes.cfm/appnote_number/3960

Does it resemble anything you've ever seen? It looks truly ghastly to
program. For example, allowing printf() to use floats adds 3500 bytes
to a program binary.

It looks like yet-another-risc-processor which doesn't program well
using c . Where other players in the field (like TI) discovered
programming a risc processor takes a lot of code to do something. The
MSP430 series is extremely efficient when it comes to code size.

 

[CBFalconer]

.... snip ...

if(resistance < 0.0)
{
fprintf(stderr,\
"My-Program: calculate_current():\n\
Your resistance is negative (%.2f), you must be kidding right? Aborting.\n",\
resistance);

return SUCKS;
}

There is no need to use those continuation lines, which just
distort your code. A '\n' is just another whitespace char. to a C
compiler. In addition strings separated by only whitespace are
automatically concatenated. You can be much clearer with:

BOOL calculate_current(double resistance, double voltage, double
*current)
{
if (debug) {
fprintf(stderr, "calculate_current: %f %f\n",
resistance, voltage);
}
if (resistance < 0.0) {
fprintf(stderr, "My-Program: calculate_current():\n"
"Your resistance is negative (%.2f),"
" you must be kidding right? Aborting.\n",\
resistance);
return SUCKS;
}
else /* whatever */;
}

Note how I try to associate a format specifier with the appropriate
object. By the way, negative resistance normally implies an
amplifier.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

 

[CBFalconer]

.... snip ...

Of course I comment the source code - I was just making the point
that you don't always want some "version" number written as a
comment in the C source file. There can be better ways to handle
revision control than typing a number into each source file.

Look at the documentation for your version control system. There
is almost certainly a way of automatically updating a version
comment when the source is checked in. No pain whatsoever.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

 

[Jan Panteltje]

Deadlines. That's another reason for the software to be the far from
perfect.

Yes, but it is realy bad not to check return values.
In fact the soft would be worth absolutely nothing.

By MISRA rules, if a function returns an error value, this value should
be checked. However not checking the return code is the very common
mistake. The exception mechanism was invented to prevent this sort of

^^^^^^^^

Yes a _mistake_, do not make these!!

mistakes.

And nothing happens. The error is unnoticed, fread() reads the garbage,
the garbage is processed, and there is garbage at the output.

Yo uare just from school right?
#include <stdio.h>
#include <stdlib.h>

main()
{
FILE *fptr = 0;
char buffer[100];
size_t bytes_read;

fptr = fopen ("flipflap", "r");

// size_t fread(void *ptr, size_t size, size_t nmemb, FILE *stream);
bytes_read = fread(buffer, sizeof(char), 100, fptr);

fprintf(stderr, "bytes_read=%d\n", (int)bytes_read);
}

Compile this:
grml: ~ # gcc -o test3 test3.c

Run it:
grml: ~ # ./test3
zsh: segmentation fault ./test3

Create the missing file:
grml: ~ # touch flipflap
grml: ~ # ./test3
bytes_read=0


You should REALLY and I mean _REALLY_ have a good read at libc.info.
You can find it in /usrshare/libc.info* on a Linux system.
It will take you a few month.
After that you will check return values.

Good for you.
Have you ever wrote anything longer then "Hello World" ?

My programs are used all over the globe.
Several are downloaded each day from my site.
I get very very few problems reported, and it runs on many systems.


Try to learn, else you will always talk crap.

 

[Jan Panteltje]

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, work at the lowest possible levels of
abstraction, use no OS, test exhaustively, and are entirely pragmatic
about the consequences of a jet engine failing. And most of the
"programmers" are actually engineers.

John

So?

 

[Vladimir Vassilevsky]

Apparently so. Did you miss the part where he expressed his desire to
be a member of the MS crew?

That would be an honor to have MS on my client list.

Given his post, I'd sure never hire the guy.

Go to hell. No problem. I can afford not working for fools.

"However not checking the

return code is the very common mistake. The exception mechanism was
invented to prevent this sort of mistakes."

No, Vladimir. Learning how to program properly was invented to prevent
this sort of mistakes[SIC].

People are weak. They do mistakes much more often then the machine does.
The more they are restricted and abstracted, the less likely they will
screw up. Look at the tremendous success of labview, matlab and
automatic code generation tools.

"Exceptions" just add another level of bloat

to protect scriptkiddies from their ignorance.

You got to understand that the programming is no longer the black art
for the chosen ones, but a dirty work for the cheap bunch.

And who's to say the guy who wrote the exception routines wasn't just
as sloppy of a "programmer" as the idiot who's depending on the machine
to do his thinking for him?

There is a difference.
There should be one smart guy to create the development framework, so
the bunch of mediocrits can use it.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

http://www.abvolt.com

 

[John Larkin]

["Followup-To:" header set to sci.electronics.design.]
John Larkin wrote:

The MC68332 is about old enough to vote, innit?

Yup. Freescale would like to kill it, but there are enough users that
they can't.

That's seomthing I'll never understand. Why would they want to kill it?
Everything's just there; all they have to do is just make the damn things.
It doesn't cost them a bit, so why stop?

robert

It's made on some older fabs that they might prefer to retire.

What they really ought to do is port it to a modern CMOS line, cut the
die size by 4:1 or so, and run it at 100 MHz!

I have, incidentally, recently tested the 16 MHz, 3.3 volt version at
various clock rates. It seems to fail at 45 MHz, so we've decided it's
safe to run them at 20.

John

How much lower does it quit at the high temperature extreme?

Didn't try that. CMOS seems to generally slow down a few tenths of a
per cent per degree C (anybody got better numbers?) so we probably
have lots of margin at 20 MHz.

John

 

[John Larkin]

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

 

[John Larkin]

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

 

[Vladimir Vassilevsky]

^^^^^^^^

Yes a _mistake_, do not make these!!

The road to hell is build of good intentions.
If everybody could be always perfect, we would live in the perfect world.

Yo uare just from school right?

Independent contractor, Ph.D., ~20 years experience, ~10..15 projects
per year, automotive, instrumentation, DSP, the products are
manufactured in the quantities ~ tens of thousands units p.a., customers
worldwide.

JFYI: there are no such things as char, int, float, double.
There are machine independent u8, s8, f32, s32 and such.

You should REALLY and I mean _REALLY_ have a good read at libc.info.

Don't care. This is a task for juniors.

You can find it in /usrshare/libc.info* on a Linux system.

I don't share the views of linux opensource gnu maniacs.

It will take you a few month.
After that you will check return values.

A lousy C programmer is teaching me. First, you should learn how to
write clear, safe and portable code.

My programs are used all over the globe.
Several are downloaded each day from my site.

URL?


Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

http://www.abvolt.com

 

[Jan Panteltje]

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.