Hi all,
I am looking for a good and cost effective full
compiler for MSP430. Anyone can help.....
Rgds,
Jerry
Good Compiler for the MSP430
Started by ●February 13, 2004
Reply by ●February 13, 20042004-02-13
There are so many C compilers for the MSP430 that it is not even funny :-)
Almost if not all commercial ones have fully functional demos. Prices range
from $199 (ours) to > $2.5K (IAR) and everything in between (Quadravox,
CrossWork, and now HiTech?) and then of course there's the "free" GCC for
MSP430. So try them out and see for yourself which one you like!
Almost if not all commercial ones have fully functional demos. Prices range
from $199 (ours) to > $2.5K (IAR) and everything in between (Quadravox,
CrossWork, and now HiTech?) and then of course there's the "free" GCC for
MSP430. So try them out and see for yourself which one you like!
Reply by ●February 13, 20042004-02-13
Jerry Daniel J wrote:
> I am looking for a good and cost effective full compiler for
> MSP430. Anyone can help.....
I'm using Imagecraft ICC430 and MSPGCC, both are cost effective
and great compilers. With MSPGCC I have had to learn a bit of it's
internals to quickly fix bugs I have found. With ICC430, all
bugs/annoyances in compiler I have noticed and reported in beta
releases, have been fixed quickly (under a day or so), never had
problems with stable releases. Plus imagecrafts USB dongle is a
great idea ;)
Indrek
--
Indrek Rebane | Borthwick-Pignon
Electronics Engineer | Tartu Science Park
Phone: (+372) 7 302 641 | Riia 185, 51014 Tartu
Fax: (+372) 7 383 041 | Estonia
indrek@indr... | www.bps.co.ee
> I am looking for a good and cost effective full compiler for
> MSP430. Anyone can help.....
I'm using Imagecraft ICC430 and MSPGCC, both are cost effective
and great compilers. With MSPGCC I have had to learn a bit of it's
internals to quickly fix bugs I have found. With ICC430, all
bugs/annoyances in compiler I have noticed and reported in beta
releases, have been fixed quickly (under a day or so), never had
problems with stable releases. Plus imagecrafts USB dongle is a
great idea ;)
Indrek
--
Indrek Rebane | Borthwick-Pignon
Electronics Engineer | Tartu Science Park
Phone: (+372) 7 302 641 | Riia 185, 51014 Tartu
Fax: (+372) 7 383 041 | Estonia
indrek@indr... | www.bps.co.ee
Reply by ●February 13, 20042004-02-13
Hi,
a full compiler means a compiler which does minimal semantic checks and
produces warnings e. g. for undefined expressions like
a[i] = i++;
a = a++;
a ^= b ^= a ^= b;
and undefined function calls like
memmove (b, ++b, 9);
and always right/wrong condiditons like
if (1)
if (unsigned_char_foo < 12345)
Many compilers like the 1.x and 2.x IAR are no such full compilers; they
do accept all of the above!
I haven't tested other commercial compilers but the gcc does accept none
of these semantik errors without a warinig.
Before you decide to really pay money for a compiler you should do
checks with undefined expressions, undefined function calls and alsways
right/wrong conditions because the standard says that undefined
expressions can do everything e. g. hangup, reboot , write into flash
and other things.
Regards
Rolf F.
a full compiler means a compiler which does minimal semantic checks and
produces warnings e. g. for undefined expressions like
a[i] = i++;
a = a++;
a ^= b ^= a ^= b;
and undefined function calls like
memmove (b, ++b, 9);
and always right/wrong condiditons like
if (1)
if (unsigned_char_foo < 12345)
Many compilers like the 1.x and 2.x IAR are no such full compilers; they
do accept all of the above!
I haven't tested other commercial compilers but the gcc does accept none
of these semantik errors without a warinig.
Before you decide to really pay money for a compiler you should do
checks with undefined expressions, undefined function calls and alsways
right/wrong conditions because the standard says that undefined
expressions can do everything e. g. hangup, reboot , write into flash
and other things.
Regards
Rolf F.
Reply by ●February 13, 20042004-02-13
Hi,
I have done a lot of "safety critical" software work in the past.
A couple of points:
1. All compilers - [in fact, all software!] - have bugs.
2. The C language is VERY flexible ... you can write code which looks like junk, but which is perfectly correct & legal C!
3. Compiler writers may not have the time or money or skills to add support for hundreds of useful warnings - especially for legal C.
The way I handle this is:
1. Test the compiler with a known good - but large - piece of code to check out all the constructs etc. Alternatively, write or acquire a "test suite" designed to check most of the C constructs.
2. Test the compiler with a known good - but complex - piece of code. This will check out the optimiser. [I usually use the DES encryption algorithm for this].
3. For safety I always turn the optimiser off - even for release builds. [I have been caught too often by bad optimisers]
4. Always check your code with PC-LINT or a similar code checker ... it's amazing what it can detect!
5. Port your code to Visual C or similar and see if it works in the PC environment. Use Bounds Checker or similar on this build to trap weird bugs not detectable when running on a target micro.
6. Ask the compiler vendor what test suite they use to check their compiler against. [Commercial compiler test suites are HUGE and very expensive - nevertheless the compiler vendor should be using one]
In other words, if the quality of compiled code is important to you, check, check and check again ... and use a variety of tools and techniques.
regards,
Richard
I have done a lot of "safety critical" software work in the past.
A couple of points:
1. All compilers - [in fact, all software!] - have bugs.
2. The C language is VERY flexible ... you can write code which looks like junk, but which is perfectly correct & legal C!
3. Compiler writers may not have the time or money or skills to add support for hundreds of useful warnings - especially for legal C.
The way I handle this is:
1. Test the compiler with a known good - but large - piece of code to check out all the constructs etc. Alternatively, write or acquire a "test suite" designed to check most of the C constructs.
2. Test the compiler with a known good - but complex - piece of code. This will check out the optimiser. [I usually use the DES encryption algorithm for this].
3. For safety I always turn the optimiser off - even for release builds. [I have been caught too often by bad optimisers]
4. Always check your code with PC-LINT or a similar code checker ... it's amazing what it can detect!
5. Port your code to Visual C or similar and see if it works in the PC environment. Use Bounds Checker or similar on this build to trap weird bugs not detectable when running on a target micro.
6. Ask the compiler vendor what test suite they use to check their compiler against. [Commercial compiler test suites are HUGE and very expensive - nevertheless the compiler vendor should be using one]
In other words, if the quality of compiled code is important to you, check, check and check again ... and use a variety of tools and techniques.
regards,
Richard
Reply by ●February 13, 20042004-02-13
Hi,
yes, that's right but for good software that's only the beginning
because without a prettyprinter/beautyfier like indent you're wasting
time for prettyprintig and also produce extra errors. And for more than
hello world programs you need a system like CVS.
Because a good editor like emacs (+etags, +cvs, maybe +indent ...) can
do this gcc + emacs is much better (and free and open source) than an
IDE without these nessisary features like the ones from IAR.
Regards
Rolf F.
yes, that's right but for good software that's only the beginning
because without a prettyprinter/beautyfier like indent you're wasting
time for prettyprintig and also produce extra errors. And for more than
hello world programs you need a system like CVS.
Because a good editor like emacs (+etags, +cvs, maybe +indent ...) can
do this gcc + emacs is much better (and free and open source) than an
IDE without these nessisary features like the ones from IAR.
Regards
Rolf F.
Reply by ●February 13, 20042004-02-13
Augmentics (MSP430) wrote:
> Hi,
>
> I have done a lot of "safety critical" software work in the past.
>
> A couple of points:
>
> 1. All compilers - [in fact, all software!] - have bugs.
Bullshit! ;@}
Honestly this is the sort of urban myth attitude that leads to buggy
code. If You set out with the idea that there will be bugs you will be
proved right. If you plan and design all stages of development
methodically, and plan to end up bug free you have a fair chance of
doing so.
Throughout the late 70's to the mid 80's most of my work was 'safety
critical'. Things like gas plants, cat crackers, Oil refinerys, Oil
platforms, gas controllers. More than 100 of these systems are still in
use today, having run 24 hours a day since installation, with no
recorded, or reported/detected software errors. beleive me if you stuff
up the code on a cat cracker you'll know about it. In addition I could
point to many other non critical designs that have been running for
years, some in extremely large volumes, without any detected software
errors, most of these are as originally shipped. You might say "well
there are probably bugs, they just haven't shown up yet". A bug is a bug
if it doesn't operate as designed, and can be seen to do so. ie if the
system doesn't operate as designed, but doesn't affect the operational
design, and cannot be observed to deviate from the designed operation in
any way, it has no effect, and therefore cannot be a bug.
Of course not all designs are like this, I've had a few shockers, but
most often the cause of buggy code is poor planning and rushing a job.
Even a job that takes a couple of years might end up being rushed
because the client changes things every 5 minutes, faster than they can
keep the spec updated.
Al
> Hi,
>
> I have done a lot of "safety critical" software work in the past.
>
> A couple of points:
>
> 1. All compilers - [in fact, all software!] - have bugs.
Bullshit! ;@}
Honestly this is the sort of urban myth attitude that leads to buggy
code. If You set out with the idea that there will be bugs you will be
proved right. If you plan and design all stages of development
methodically, and plan to end up bug free you have a fair chance of
doing so.
Throughout the late 70's to the mid 80's most of my work was 'safety
critical'. Things like gas plants, cat crackers, Oil refinerys, Oil
platforms, gas controllers. More than 100 of these systems are still in
use today, having run 24 hours a day since installation, with no
recorded, or reported/detected software errors. beleive me if you stuff
up the code on a cat cracker you'll know about it. In addition I could
point to many other non critical designs that have been running for
years, some in extremely large volumes, without any detected software
errors, most of these are as originally shipped. You might say "well
there are probably bugs, they just haven't shown up yet". A bug is a bug
if it doesn't operate as designed, and can be seen to do so. ie if the
system doesn't operate as designed, but doesn't affect the operational
design, and cannot be observed to deviate from the designed operation in
any way, it has no effect, and therefore cannot be a bug.
Of course not all designs are like this, I've had a few shockers, but
most often the cause of buggy code is poor planning and rushing a job.
Even a job that takes a couple of years might end up being rushed
because the client changes things every 5 minutes, faster than they can
keep the spec updated.
Al
Reply by ●February 13, 20042004-02-13
Hi,
This is getting fun! It sounds like we have similar backrounds Al.
I too used to think that I could find all the bugs in a system.
However a while back I was hired to do the safety module in a nuclear system
handling plutonium.
For the first [and last!] time in my life I had plenty of budget for test
time etc.
One smallish module took 2 weeks to design, 2 weeks to implement ... and
then I was FORCED to test it for EIGHT weeks.
"As usual" I found all (?) the bugs in the first week or so ... but we HAD
to test for SEVEN more weeks.
So I wrote zillions of test cases, random data generators etc etc -
primarily in order to justify my pay.
You can therefore imagine how startled I was to see the next errors pop up
after a further FOUR weeks or so.
A couple more surfaced at the seven week mark.
I simply couldn't believe this - after all, I was a very experienced [and in
my own opinion, a good] software engineer and yet bugs were still in my
code!!!!
Clearly I checked these bugs out in great detail - all of them were the
result of very, very subtle timing interactions between processes, hardware,
data etc.
All our code was peer reviewed, and nobody spotted these during the reviews.
We also [for a change!] had tons of reqs docs, design docs, coding docs etc
etc.
This experience showed me that even I, Mr Supercoder [hah!], could NOT
guarantee to write 100% bug proof code.
Since then I have done quite a lot of work in the software quality area, and
have seen similar stories and related studies.
I have also done some "forensic" software assigments for venture capital
companies to check out the code quality used in products they have invested
in ... you really do NOT know what sort of "interesting" code, processes etc
I found during this work ...
To summarise, I am no longer so convinced that I - or the software tools
that I rely on - can produce 100% bug free code, so I am very much more
cautious.
At the end of the day it comes down - as you say - to "when is a bug not a
bug".
A bug which appears within 10 seconds is detected and fixed by the coder.
A bug which appears once per million hours is probably not a problem in real
life ... except for nuclear reactor safety systems, nuclear weapons fuses
and the like.
A bug which appears once every 12 weeks is the bummer which we need to
prevent - they don't show during testing but do show up in real life.
Anyway, assuming that I have had at least of couple of bug spawning "bad" or
"lazy" days during a project, I use whatever tools I can find to locate any
bugs inadvertently lying about! Can't do any harm, only takes an extra day
or so ... and could prevent that 3AM "callout" to some God forsaken hole to
fix a bug which has been missed.
Richard
This is getting fun! It sounds like we have similar backrounds Al.
I too used to think that I could find all the bugs in a system.
However a while back I was hired to do the safety module in a nuclear system
handling plutonium.
For the first [and last!] time in my life I had plenty of budget for test
time etc.
One smallish module took 2 weeks to design, 2 weeks to implement ... and
then I was FORCED to test it for EIGHT weeks.
"As usual" I found all (?) the bugs in the first week or so ... but we HAD
to test for SEVEN more weeks.
So I wrote zillions of test cases, random data generators etc etc -
primarily in order to justify my pay.
You can therefore imagine how startled I was to see the next errors pop up
after a further FOUR weeks or so.
A couple more surfaced at the seven week mark.
I simply couldn't believe this - after all, I was a very experienced [and in
my own opinion, a good] software engineer and yet bugs were still in my
code!!!!
Clearly I checked these bugs out in great detail - all of them were the
result of very, very subtle timing interactions between processes, hardware,
data etc.
All our code was peer reviewed, and nobody spotted these during the reviews.
We also [for a change!] had tons of reqs docs, design docs, coding docs etc
etc.
This experience showed me that even I, Mr Supercoder [hah!], could NOT
guarantee to write 100% bug proof code.
Since then I have done quite a lot of work in the software quality area, and
have seen similar stories and related studies.
I have also done some "forensic" software assigments for venture capital
companies to check out the code quality used in products they have invested
in ... you really do NOT know what sort of "interesting" code, processes etc
I found during this work ...
To summarise, I am no longer so convinced that I - or the software tools
that I rely on - can produce 100% bug free code, so I am very much more
cautious.
At the end of the day it comes down - as you say - to "when is a bug not a
bug".
A bug which appears within 10 seconds is detected and fixed by the coder.
A bug which appears once per million hours is probably not a problem in real
life ... except for nuclear reactor safety systems, nuclear weapons fuses
and the like.
A bug which appears once every 12 weeks is the bummer which we need to
prevent - they don't show during testing but do show up in real life.
Anyway, assuming that I have had at least of couple of bug spawning "bad" or
"lazy" days during a project, I use whatever tools I can find to locate any
bugs inadvertently lying about! Can't do any harm, only takes an extra day
or so ... and could prevent that 3AM "callout" to some God forsaken hole to
fix a bug which has been missed.
Richard
Reply by ●February 14, 20042004-02-14
Don't get me wrong, I'm not for 1 second claiming infallibility,
far
from it, I've had my fair share of doozies, and even now don't get it
right every time, but I never set out thinking negatively.
--- In msp430@msp4..., "Augmentics \(MSP430\)" <ymsp430@a...>
wrote:
> Hi,
>
> This is getting fun! It sounds like we have similar backrounds Al.
>
> I too used to think that I could find all the bugs in a system.
> However a while back I was hired to do the safety module in a nuclear system
> handling plutonium.
> For the first [and last!] time in my life I had plenty of budget for test
> time etc.
> One smallish module took 2 weeks to design, 2 weeks to implement ... and
> then I was FORCED to test it for EIGHT weeks.
> "As usual" I found all (?) the bugs in the first week or so ... but we HAD
> to test for SEVEN more weeks.
One of the most critical jobs I did was at a Saudi gas plant, the
largest plant in the world at that time. The system had been in place
for 2 years, but nobody from the company would go and work on it, not
even the US HQ guys, nobody had lasted more than 3 days in country. I
was hired on january 4th 1980, flew out on january 14th 1980. I'd
never worked on the systems before, or even in that field, certainly
it was my first petrochemical industry job. The system installed had
been superceded so I had no experience of it, just a programmers
pocket reference, and an assembly language reference. The job was
complicated by the fact that it was incomplete. The most critical
section of the design was the catalytic cracker, this was to be
upgraded to a regenerative type sometime after I left, so my design
had to detect the presence of this automatically. It took me a week to
absorb the design and assembler, about 2 weeks to plan the software, 3
-4 days to write it, so by mid february I was ready for testing,
testing was mildly interrupted in mid March, when the Korean
contractors collapsed the false floor under my desk, 5 days later,
with a dislocated hip and broken knee I carried on testing, from a
wheelchair. By mid-April I was satisfied that I couldn't even
deliberately break the system. My debug included over-riding safety
switches, sending false valve position data, forcing failures in the
middle of a movement etc, up to 4 failures at a time, any of which
would be detected by the system before it could become an issue. On
28th April, after watching the beast run in anger for 2 weeks, which
included two maintenance cycles I left. This was 1980. In 1993 I
returned to the site, while on other business, it had had no downtime
except for maintenance, or hardware replacement since I left. Even the
automated update to regen had gone smoothly. I figure that at a 1msec
program execution cycle, 410,248,800,000 (410 billion) execution
cycles would constitute bug free, since even the bits start wearing
out by then ;@}
> So I wrote zillions of test cases, random data generators etc etc -
Random data generators are OK, so long as you run them such that every
combination occurs several time, and they can't detect faults that are
sequence related.
> primarily in order to justify my pay.
> You can therefore imagine how startled I was to see the next errors pop up
> after a further FOUR weeks or so.
> A couple more surfaced at the seven week mark.
>
> I simply couldn't believe this - after all, I was a very experienced [and in
> my own opinion, a good] software engineer and yet bugs were still in my
> code!!!!
>
> Clearly I checked these bugs out in great detail - all of them were the
> result of very, very subtle timing interactions between processes, hardware,
> data etc.
And then there are the failures! The most frustrating of these cost
weeks of debug, nothing found, couldn't crash it within reasonable
efforts, and it failed first day out in the field because one of the
main signals coming into the system was noisy as hell, and it had been
allowed for, however there was a fault in the input filter, a single
mistyped characater as it turned out, that didn't cause a problem with
pseudo noise, but crashed and burned in the real world.
> All our code was peer reviewed, and nobody spotted these during the reviews.
> We also [for a change!] had tons of reqs docs, design docs, coding docs etc
> etc.
>
> This experience showed me that even I, Mr Supercoder [hah!], could NOT
> guarantee to write 100% bug proof code.
> Since then I have done quite a lot of work in the software quality area, and
> have seen similar stories and related studies.
> I have also done some "forensic" software assigments for venture capital
> companies to check out the code quality used in products they have invested
For a few years I specialised in simulation software, designing system
that you'd plug into, say a submarine, and it would determine exactly
which gate or memory cell had failed. That opens your eyes to
designing robust tests, and, although the system tested hardware it
was the softare you wrote that mattered. I use the things I learnt
then to debug my own code.
> in ... you really do NOT know what sort of "interesting" code, processes etc
> I found during this work ...
Believe me nothing would surprise me. I said here before that most of
my contracts in Australia have been to bail a company out of the shit
after it paid big bucks for work to be done, only to find out that the
'professional' company they'd hired had screwed up, and didn't know
how to get out of it.
There was the 1400 line long ISR that made nested calls to 4 levels,
in an ECU of all things, needless to say the car ran like a pig.
Then there was the 9800 line program that was all an ISR, once the
first interrupt occured the software never exited it. The programmer
just forced the control register and GI to get it to run, and kept
reforcing the stack to prevent it from overflowing.
Or the program that read a byte into ACC from an external interuppt
controller, right shifted ACC, without first saving it, called a
subroutine if CARRY became set, retunred from that sub with ACC now
corrupted, and continued to shift ACC looking for interrupt events,
but now using whatever was left in ACC after the last subroutine.
Then the moron that used absolute values in variables with masks,
rather than bit testing because "real programmers don't use bit
instructions". His answer was to replace BIS xxxx with 4 instructions.
Or the countless times I've seen chains of IF's, especially when
analysing serial comms, most of them so dumb they keep checking even
after they've resolved the issue, such as:-
CMP X,A
JZ TSTB
CALL ISA
TSTB:
CMP X,B
JZ TSTC
CALL ISC
etc
Then they wonder why they run out of memory!
> To summarise, I am no longer so convinced that I - or the software tools
> that I rely on - can produce 100% bug free code, so I am very much more
> cautious.
I use an assembler, 30 years of proven and tested asm libraries, and
check after check after check. I'm convinced that anyone can produce
bugfree code, but am not convinced that I do so every time. Now this
doesn't say that I write the code and its bug free the first time I
try it. I develop hardware and software hand in hand. Once it ships to
the client it should be bug free. However not all bugs are software of
course, and not all can be foreseen.
> At the end of the day it comes down - as you say - to "when is a bug not a
> bug".
> A bug which appears within 10 seconds is detected and fixed by the coder.
> A bug which appears once per million hours is probably not a problem in real
> life ... except for nuclear reactor safety systems, nuclear weapons fuses
> and the like.
Which all should NEVER rely on a single layer of security, but have at
least 3 independent security layers
> A bug which appears once every 12 weeks is the bummer which we need to
> prevent - they don't show during testing but do show up in real life.
>
> Anyway, assuming that I have had at least of couple of bug spawning "bad" or
> "lazy" days during a project, I use whatever tools I can find to locate any
> bugs inadvertently lying about! Can't do any harm, only takes an extra day
> or so ... and could prevent that 3AM "callout" to some God forsaken hole to
> fix a bug which has been missed.
I actually enjoy debugging, it's as close as I can get to big game
hunting, armed with just a knife, without hurting any animals. It's
more fun than planning and coding, not as much fun as seeing the final
product do its stuff, but an essential part of getting that far.
Cheers
Al
from it, I've had my fair share of doozies, and even now don't get it
right every time, but I never set out thinking negatively.
--- In msp430@msp4..., "Augmentics \(MSP430\)" <ymsp430@a...>
wrote:
> Hi,
>
> This is getting fun! It sounds like we have similar backrounds Al.
>
> I too used to think that I could find all the bugs in a system.
> However a while back I was hired to do the safety module in a nuclear system
> handling plutonium.
> For the first [and last!] time in my life I had plenty of budget for test
> time etc.
> One smallish module took 2 weeks to design, 2 weeks to implement ... and
> then I was FORCED to test it for EIGHT weeks.
> "As usual" I found all (?) the bugs in the first week or so ... but we HAD
> to test for SEVEN more weeks.
One of the most critical jobs I did was at a Saudi gas plant, the
largest plant in the world at that time. The system had been in place
for 2 years, but nobody from the company would go and work on it, not
even the US HQ guys, nobody had lasted more than 3 days in country. I
was hired on january 4th 1980, flew out on january 14th 1980. I'd
never worked on the systems before, or even in that field, certainly
it was my first petrochemical industry job. The system installed had
been superceded so I had no experience of it, just a programmers
pocket reference, and an assembly language reference. The job was
complicated by the fact that it was incomplete. The most critical
section of the design was the catalytic cracker, this was to be
upgraded to a regenerative type sometime after I left, so my design
had to detect the presence of this automatically. It took me a week to
absorb the design and assembler, about 2 weeks to plan the software, 3
-4 days to write it, so by mid february I was ready for testing,
testing was mildly interrupted in mid March, when the Korean
contractors collapsed the false floor under my desk, 5 days later,
with a dislocated hip and broken knee I carried on testing, from a
wheelchair. By mid-April I was satisfied that I couldn't even
deliberately break the system. My debug included over-riding safety
switches, sending false valve position data, forcing failures in the
middle of a movement etc, up to 4 failures at a time, any of which
would be detected by the system before it could become an issue. On
28th April, after watching the beast run in anger for 2 weeks, which
included two maintenance cycles I left. This was 1980. In 1993 I
returned to the site, while on other business, it had had no downtime
except for maintenance, or hardware replacement since I left. Even the
automated update to regen had gone smoothly. I figure that at a 1msec
program execution cycle, 410,248,800,000 (410 billion) execution
cycles would constitute bug free, since even the bits start wearing
out by then ;@}
> So I wrote zillions of test cases, random data generators etc etc -
Random data generators are OK, so long as you run them such that every
combination occurs several time, and they can't detect faults that are
sequence related.
> primarily in order to justify my pay.
> You can therefore imagine how startled I was to see the next errors pop up
> after a further FOUR weeks or so.
> A couple more surfaced at the seven week mark.
>
> I simply couldn't believe this - after all, I was a very experienced [and in
> my own opinion, a good] software engineer and yet bugs were still in my
> code!!!!
>
> Clearly I checked these bugs out in great detail - all of them were the
> result of very, very subtle timing interactions between processes, hardware,
> data etc.
And then there are the failures! The most frustrating of these cost
weeks of debug, nothing found, couldn't crash it within reasonable
efforts, and it failed first day out in the field because one of the
main signals coming into the system was noisy as hell, and it had been
allowed for, however there was a fault in the input filter, a single
mistyped characater as it turned out, that didn't cause a problem with
pseudo noise, but crashed and burned in the real world.
> All our code was peer reviewed, and nobody spotted these during the reviews.
> We also [for a change!] had tons of reqs docs, design docs, coding docs etc
> etc.
>
> This experience showed me that even I, Mr Supercoder [hah!], could NOT
> guarantee to write 100% bug proof code.
> Since then I have done quite a lot of work in the software quality area, and
> have seen similar stories and related studies.
> I have also done some "forensic" software assigments for venture capital
> companies to check out the code quality used in products they have invested
For a few years I specialised in simulation software, designing system
that you'd plug into, say a submarine, and it would determine exactly
which gate or memory cell had failed. That opens your eyes to
designing robust tests, and, although the system tested hardware it
was the softare you wrote that mattered. I use the things I learnt
then to debug my own code.
> in ... you really do NOT know what sort of "interesting" code, processes etc
> I found during this work ...
Believe me nothing would surprise me. I said here before that most of
my contracts in Australia have been to bail a company out of the shit
after it paid big bucks for work to be done, only to find out that the
'professional' company they'd hired had screwed up, and didn't know
how to get out of it.
There was the 1400 line long ISR that made nested calls to 4 levels,
in an ECU of all things, needless to say the car ran like a pig.
Then there was the 9800 line program that was all an ISR, once the
first interrupt occured the software never exited it. The programmer
just forced the control register and GI to get it to run, and kept
reforcing the stack to prevent it from overflowing.
Or the program that read a byte into ACC from an external interuppt
controller, right shifted ACC, without first saving it, called a
subroutine if CARRY became set, retunred from that sub with ACC now
corrupted, and continued to shift ACC looking for interrupt events,
but now using whatever was left in ACC after the last subroutine.
Then the moron that used absolute values in variables with masks,
rather than bit testing because "real programmers don't use bit
instructions". His answer was to replace BIS xxxx with 4 instructions.
Or the countless times I've seen chains of IF's, especially when
analysing serial comms, most of them so dumb they keep checking even
after they've resolved the issue, such as:-
CMP X,A
JZ TSTB
CALL ISA
TSTB:
CMP X,B
JZ TSTC
CALL ISC
etc
Then they wonder why they run out of memory!
> To summarise, I am no longer so convinced that I - or the software tools
> that I rely on - can produce 100% bug free code, so I am very much more
> cautious.
I use an assembler, 30 years of proven and tested asm libraries, and
check after check after check. I'm convinced that anyone can produce
bugfree code, but am not convinced that I do so every time. Now this
doesn't say that I write the code and its bug free the first time I
try it. I develop hardware and software hand in hand. Once it ships to
the client it should be bug free. However not all bugs are software of
course, and not all can be foreseen.
> At the end of the day it comes down - as you say - to "when is a bug not a
> bug".
> A bug which appears within 10 seconds is detected and fixed by the coder.
> A bug which appears once per million hours is probably not a problem in real
> life ... except for nuclear reactor safety systems, nuclear weapons fuses
> and the like.
Which all should NEVER rely on a single layer of security, but have at
least 3 independent security layers
> A bug which appears once every 12 weeks is the bummer which we need to
> prevent - they don't show during testing but do show up in real life.
>
> Anyway, assuming that I have had at least of couple of bug spawning "bad" or
> "lazy" days during a project, I use whatever tools I can find to locate any
> bugs inadvertently lying about! Can't do any harm, only takes an extra day
> or so ... and could prevent that 3AM "callout" to some God forsaken hole to
> fix a bug which has been missed.
I actually enjoy debugging, it's as close as I can get to big game
hunting, armed with just a knife, without hurting any animals. It's
more fun than planning and coding, not as much fun as seeing the final
product do its stuff, but an essential part of getting that far.
Cheers
Al
Reply by ●February 14, 20042004-02-14
Wow - a mega response! It certainly seems that we have similar backgrounds!
I once got an offer to enhance an oil pipeline / tank farm controller .... 100k of assembler running on an obscure Italian mini computer. All assembler, no source code, just a CPU manual. Unlike you I turned this one down ... :)
I also turned down the Algerian offer - "Don't worry, we'll give you a flak jacket before you leave the plane. Two soldiers will escort you to the armoured personnel carrier and will drive you to work. They will also be your bodyguards." I don't think so.
However for several other projects I HAVE worked on sites where I have been surrounded by armed staff - including one time with several looking like Rambo, with cammo jerkins, ammo belts draped across their shoulders and M60 machine guns in their arms ... seriously! Software can be fun!
Anyway, this is all off-topic - but has been interesting!
I once got an offer to enhance an oil pipeline / tank farm controller .... 100k of assembler running on an obscure Italian mini computer. All assembler, no source code, just a CPU manual. Unlike you I turned this one down ... :)
I also turned down the Algerian offer - "Don't worry, we'll give you a flak jacket before you leave the plane. Two soldiers will escort you to the armoured personnel carrier and will drive you to work. They will also be your bodyguards." I don't think so.
However for several other projects I HAVE worked on sites where I have been surrounded by armed staff - including one time with several looking like Rambo, with cammo jerkins, ammo belts draped across their shoulders and M60 machine guns in their arms ... seriously! Software can be fun!
Anyway, this is all off-topic - but has been interesting!
