This is a pointless question. Debugging is essential. If the system has bugs the optimisation is irrelevant.
When the system is debugged then you can start optimisation.
The fact that parts with more memory are getting cheaper is irrelevant. Those with less memory will be cheaper still
What is VERY worrying is that you were prepared to sacrifice quality to use a smaller (cheaper ) part. I suppose that attitude is OK in consumer mass market stuff where a lock up or reboot is not a problem. ... in some applications it can have more serious consequences
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Personally I find the best debugging tools are the same as the best software design tools - pencil, eraser, pad of paper and occasionally a calculator. Then you are forced to actually _think_about_what_you_ _are_doing_, preferably well away from your computer. Debuggers are great for finding bugs it the high-level logic of code, but mediocre at best inside complex data structures, which at least for me is where most of the problems usually are. This goes even for DDD, a full sized Unix debugger with a specific emphasis on data structures.
Premature or inappropriate use of debuggers discourages thought. OK, so this variable holds the length of that data structure. When the length changes, when does the variable get updated? Before, during, or after? If during, exactly when in the process does it happen, and do all parts of your program assume that convention? If you've got a pad full of notes in front of you resolving issues like that is straightforward. A source code listing in a debugger is much less helpful.
Consider testing support. Several development systems have simulators for the processor, but the support for simulating the external I/O is often weak. I have worked on systems on which you can write code to look at the processor outputs and changing the processor inputs to simulate external behavior. Add logging from the test code and allow the whole thing to operate from a script, so that it can be invoked automatically from the command line, rather than by clicking a mouse, and you have a powerful tool for automatic testing that I would be interested in.
While I appreciate good optimization, I agree that it is becoming less important.
I also appreciate the ability to use Standard C as much as possible, rather than resort to needless proprietary mechanisms. For example, on
8-bit processors, allow 8-bit structs and enum types, which are both allowed by the standard.
I did not see a suggestion to sacrifice quality. The job is not finished until the code runs correctly, including sufficiently fast within the chosen memory. Now, what tools are the most useful to achieve that?
There are several kinds of debugging, from pulsing an unused pin to HLL source-level debuggers with data visualizers, edit-and-continue and other whiz-bang features. Would you prefer your development system had more of the latter, even if it meant having to use more expensive parts?
Having followed this thread for a while I agree that there is a distinct divide between participants that is somewhat age/experience - centric. It should be no surprise that this will be the case.
As one of those who could hunt with nothing but a WISUI* kit I find that the best debugging is done in the early stages of development when you are still bashing sense out of the specification you get handed. You can get rid of better than 90% of all the silly errors at this stage and that is well before a single line of code is written. Then better than 90% of what errors are left can be eliminated by thorough code walk-through's. That may still leave some errors that should be eliminatable by very careful and detailed incremental testing.
WISUI = "What I Stand Up In". This can be surpisingly littel at times.
--
********************************************************************
Paul E. Bennett ....................
Forth based HIDECS Consultancy .....
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
The query was ambiguous, but seemed to be either a question about importance of skills for selling one's services or importance of features within a development tool suite. I took it as the latter. The question was NOT "which is more important -- a debugged or optimized program".
No, it isn't, but rather importance of tools targeting those activities.
Debug or test? I have used simulators for unit test and some system tests but I prefer an Ice.
After you have done the testing (white box, black box etc) you can debug...
It depends on the system as to whether optimisation is permitted or not.
Usually I add the optimisation (speed or size) as it is needed. Some times there is no need for either. In any event you need to test well and then, if required debug or modify the system.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
The latter is what I was trying to convey but obviously that wasn't as clear as I first thought (it never is).
The responses have been fantastic and I have to thank everyone for their help, I guess I'll provide some context for the question now. 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.
(Thanks for correcting my source on this quotation, by the way.)
As I noted below, and as you already knew, the context of these rules is for optimisation of the implementation, not choice of algorithm - the whole point is that choosing a better algorithm will make a bigger difference to the result than a finely tuned poor algorithm. Any time spent fine-tuning your bubble-sort implementation is time wasted - switch to a heap sort or quicksort.
As you say, it's hard to improve badly written code - but it's far from impossible to improve well-written code. If your code involves sorting (being a nice example of a problem with many different algorithms), then it is perfectly reasonable to use a thrown-together bubble sort in your first prototypes. What's important is that when you start to need something faster, you switch to a faster algorithm rather than trying to optimise the poor algorithm.
And as for the hardware, it's important that you do *not* try to pick the most optimal target at the start. You start out your development on hardware that can do more than you need, so that you have room for testing and debugging, and enough overhead so that you are not caught cold by unexpected complexities. If you think your program will take
12K, you start with a 32K device in prototyping and testing - and cut it down to 16K for production. "Premature optimisation is the root of all evil" applies to the hardware too.
The need for hand-optimising the source code (or writing critical sections in assembly) is very much less now than it used to be, as compilers have got better. Well designed code clearly helps too.
optimisations in a
irrelevant if it
The need for debugging tools varies enormously between different types of projects, and a decent hardware debugger can be useful for many things besides the obvious software debugging.
Time-limits can certainly be part of the requirements in an embedded system, and are thus part of the "correctness" side of some code. And even when it is not strictly required, speed is often important - fast code translates to slower oscillator speeds and/or longer periods of cpu sleep, leading to lower costs and lower power. But your prime concern is always to write code that works according to the requirements.
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@mpeforth.com
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
Here you are missing an option. Also consider mergesort, combined with a malloced list. For an example of this see wdfreq.c, a part of the hashlib distribution. See:
I was not intending to give a list of possible sorting algorithms - there are many, many more than the four mentioned here, and there are many things to consider if you are looking for an "optimal" solution. Sorting algorithms are fun to work with, since it is easy to understand and specify the problem, while offering a wide variety of algorithms, so a thread on the subject (or algorithm design in general) might be of general interest in c.a.e. - but it's off-topic for this thread.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.