Re: What's more important optimisations or debugging?

On Sun, 03 Jun 2007 15:47:06 -0700, Ryan H <rhapgood@xxxxxxxxx> wrote:

I'm a developer for an embedded tools company (no need for name
dropping) and will soon be focussing on improving our compilers to
support higher level debugging features. As it has been mentioned some
optimisations can make this quite difficult and whilst I will be
aiming to make high level debugging as accurate and complete as
possible I was interested in where peoples preferences are.

I know I'm a boring old fart on this topic, but I've been coding
embedded systems for 30+ years. The essential issue for me is
that the best tools for hardware bring up are not the same as
for embedded software development on working hardware with
drivers.

When I'm bringing up a new chip, what I need are one or two
LEDs and test points, an oscilloscope, plus a Flash programmer
and/or a JTAG unit.

Once I've got as far as proving chip startup code, a serial
port and an interrupt-driven timer ticker, a more software
oriented debug chain is appropriate.

But in either case, barring chip and compiler bugs, the bugs
are in the app's source code. Finding them is just application
of formal scientific method.

While bugs are known to exist
observe this bug
form a hypothesis
derive experiment and test
until this bug is fixed
repeat

Note that there are two loops, the inner one being crucial.
The faster you get round the inner loop, the faster you
debug. The key part is teaching people to observe, and then
teaching them to design experiments with yes/no answers.
All the numbers I've seen about software costs indicate that
people debug code for two or three times as long as it takes
them to write it. I rate debugging as far more important
than compiler optimisation.

But the people issue is in turn far more important than
the tool chain. Paul Bennett's comment is relevant. Some
people can debug with their hands in their pockets; others
just never learn to debug efficiently.

Stephen

--
Stephen Pelc, stephenXXX@xxxxxxxxxxxx
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
.

Relevant Pages

  • Re: debugging in release mode
    ... As long as the optimizing compiler is helping my bugs to appear, ... shows the differences between the default debug mode and the default release ... and then turn off optimizations and turn on generation of debug ...
    (microsoft.public.vc.mfc)
  • Re: debugging in release mode
    ... I have no doubt that it's a problem of mine and not of the compiler. ... I don't really need optimization ... for the sake of memory space or execution speed. ... shows the differences between the default debug mode and the default release ...
    (microsoft.public.vc.mfc)
  • Re: .NET Umgebung mit MFC von Visual C 6 nutzbar?
    ... den Compiler vermisse ich in einigen Details ... Zu glauben das es irgendwo Bugs ... > Was hast Du für Probleme mit mit CFileDialog? ... Nachdem ich diese Fehler hatte bin ich dann kurzerhand wieder auf VS6 ...
    (microsoft.public.de.vc)
  • Re: compiler bugs
    ... well known verification techniques? ... think of the kind of bugs you experience. ... (Most compiler code is ... many of the subtle bugs come from using grey-areas, ...
    (comp.compilers)
  • Re: Perform Thru/Go to vs. Perform - Compile Speed
    ... >>and customers with such large programs must sometimes do what is ... a thing" is irrelevant when it comes to what a compiler encounters. ... the bugs being mentioned were "not an infrequent ... restictions -- it's difficult to support a rewrite just on accounta it looks ...
    (comp.lang.cobol)