On Tue, Jun 24, 2003 at 10:14:46PM +0300, Peter L. Peres wrote:
> I think that having the try/catch/throw construct work at any nesting
> level youd be a great thing, even if the struct passed would have to
> evaluate to a simple byte or word evaluating to an integer code. I know=
 it
> is very hard because of the inaccessible stack on the smaller pics.

Yes, it's not possible to do it without major performance penalties. You
need to push a snapshot of the current execution environment at each
"try", and then restart from there when an exception is thrown. When
you leave the "try" block witouth an exception, the snapshot is poped
from the "exception stack". This approach was called "sjlj" in gcc's
slang (for setjump/longjump).

In modern (big) procesors, another technique can be used, that involves
unwinding the stack using information similar to debug information
embeded in the program code. That's is what gcc does in current versions
on supported architectures. This way, you have _no_ performance penalty
when not throwing an exception.

In PIC's all of the above is very difficult, so it's better to leave
exception handling outside if you want performance from your code, you
can use error fields in objets to signal errors and then check the
fields when it's needed.

I certainly like C++ for embeded programming, I have programed for
PalmOS (motorola 68k, limited to 64kb code and 64kb "local" data),
and found that programing correctly (and without using exceptions and
RTTI) a C++ program can be faster and smaller than the equivalent C
program (that's using gcc and g++). You have to be clever and actually
understand what the compiler is doing to archive that, but I think that
is a must in embeded programming.

Some useful techniques are:
 * Not allocating objets from stack: Objets allocated in the stack need
   an stack allocator, stack pointer, etc. thar really hurts on code
   size, adding complexity to your functions. =BFDo you really need
   dynamic object allocation?
 * Using static methods whenever posible: Many objets you program are
   meant to be used only once in the program. So, making the methods
   static you avoid passing the object pointer to the method, and avoid
   indirect memory acces (througth the object's "this" pointer) to each
   field.
 * Using inline methods: Inline methods are very efficient, the compiler
   can optimize they and eliminate the object pointer completely. The
   downside is added code size, but in simpler methods it's not much.


    Daniel.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads