AVR-Chat

> >Detection of failure to preserve registers inside interrupt handlers
> >is almost operational, and other facilities are planned.
> 
> That's a very nice feature, it will save a lot of head-scratching.
Not far off, but not foolproof either. To be done properly, full
variable analysis is required (tracking the contents of variables), eg.
to detect that the sreg has been saved and restored, since this requires
I/O as well as just simple push/pop (which is easier to track).
 
> Usage of ram, and register variables would be interesting.
> IE who mucks with Thingy_pointer or  Other_thingy appears unused..
Not sure exactly what you mean here, all refs to a variable can be
displayed, and the symbol table display shows unreferenced symbols.
 
> Possibly spotting variables in the upper register bank that could be moved
> to lower, or moved to ram with minimal impact..
> Code segs that could be profitably made into subroutines.
These are more in the optimization/hints category, rather than
debug/error detection.
I plan on these a bit further down the track, though some could be done
soon.
Other possibilities include:-
* Detection of unused operation results (eg. alter a variable, then
without using the new value, alter it again). 
* Calculation of maximum stack depth to detect collision with variable
storage.
* Identification of code that is executed on many flow paths, but only
needed on some (eg. push a var, then branch around stuff, and pop again.
The push/pop could be moved inside the "stuff" so that it's done only
when needed).
* Calculation of path lengths to come up with maximum execution and
interrupt service times.
and probably many more...

> I wrote one application where I deliberately overlapped my input buffer,
> output buffer, and stack space in SRAM, but with careful design, it was fine.
*Very* careful I imagine. I'd just use the next chip up, with more RAM
;-)

Rob