Hello Jan,

Thanks for the long note. I see your point of view on most items.

It is interesting how each person's experience affects the way they do things. In most of the projects I have worked on, there has been piece of external RAM to work with. And, in most of the projects I have worked on, execution speed has not been an issue except in very isolated situations. As a result, I tend to worry more about conserving program space than RAM.

I also have a "less code == fewer bugs" mentality that keeps me pointed in the same direction.

One place I do disagree with you is the "caller saves registers" vs. "callee saves registers" issue. Presumably, any given subroutine will be (or at least might be) called from multiple places in a big program. If the subroutine promises to clean up after itself, then the saving and restoring only has to be done once in the subroutine itself, instead of all over the place by the callers. This means less code and fewer oppotunities for mistakes (see above).

A worse problem appears if a widely-used subroutine in a big program suddenly decides it needs to use another register. If the subroutine does not save/restore that register, then you have to investigate every place that calls it and possibly make numerous adjustments throughout the program. That is an excellent recipe for creating new bugs.

I suppose this boils down to a big program vs. little progam tradeoff. In a little program, it's easy enough to use either way ("caller saves" or "caleee saves") or even to mix them, as you said. But in a bigger progam, I think you are asking for trouble with "caller saves".

Perhaps all big programs should be written in C. (c:

-- Russ