> 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. >
I've been down that road too. > 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. > The one project I did which actually needed the code compressor was very much CPU bound - I had an 8 MHz crystal, but I had an interrupt routine with a fair amount of processing running at 10 KHz. The interrupt routine was hand-written assembly, as were a number of other parts of the code. Without the code compressor, it would have taken 105% of the 8K flash. With the code compressor on, it came in at around 95-98%. However, that was a couple of years ago. If I compile the same program now, with the latest compiler, it will compile to something like 90% without compressing, because the code generator is better. My point, you see, is not that the code compressor is inherintly bad, it is just that it is misplaced effort. Had Richard not bothered with the code compressor in the first place, but rather spent that time making other improvements to the code generator, then it would never have been needed. Now that it's done, then as long as it does no harm and does not take up development time that would be better spent on more useful improvements, ImageCraft should keep it - even though there is no doubt in my mind that it is verging on useless in practice, it is still a good sales point. However, there should be a way to completly disable its effects (in particular, the jumble it makes of switch statements, and the unnecessary extra layer in function pointers), and I hope it never gets added to the icc-msp compiler. > 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 >
