David Brown wrote: [snippage]
>I would love for Richard to drop the code compressor. In my experiance, it >is quite simply not worth the effort. In effect, finds common expressions >in the generated object code and makes them into little subroutines. I have >seldom found that it saves more than about 10%, and it makes the executable >slightly slower and messes with debugging (stepping through code at an >assembly level jumps all over the place, and breakpoints can get messy). >With the AVR chips getting bigger memories all the time, it is simply not >worth it. I think he would be far better dropping the code compressor and >concentrating on other optomisations which would improve the code size much >more and often speed up execution. Common sub-expression elimination at the >source code level would have more effect, and without the code compressor, >the code generated for switches could be vastly improved. Yes, for new designs, that's certainly true. However, when the customer comes back and demands some feature be shoehorned in, it can be a saving grace. You can argue that a large part should have been picked, yada yada yada, but most products are driven by cost, and you don't throw in a Mega128L when a '4433 is cheaper, meets the I/O needs, and generally does what you want. Yes, it's irritating to debug compressed code. However, in my experience of playing with it, you don't go to compressing until you need it. Which means the core code already works, and any breakage is probably in the new features. If necessary, for the purposes of debugging, you cut out as much old code as possible (like help menus...) to avoid compressing while debugging. And I have to say I have yet to see the compressor introduce a bug. True, it's slower. However, a protocol converter running on a 4.9152Mhz at 9600 baud isn't exactly CPU bound. Speed is not often (and rarely, in my 20+ years of experience) the driving factor in the selection of a micro. A lot of times it's simply a supersmart PAL, or some other mundane feature. Now, admittedly, at Hayes (where I worked on the Optima series modems) we had both a 44Mhz Matra part that was the V.34 engine, and we were pulling every trick in the books to eek out every last cycle. We also used the Dallas DS80C320 series, but actually got better performance out of the Matra because of our instruction mix. There are times the code compressor is not the appropriate tool, and there are times it is. Summarily wishing to dispose of it isn't a good idea, in my book. The idea is to provide as many tools for the developer, and let *them* make the choice about what tool is appropriate for their solution. --John
