[avr-chat] A new AVR architecture

[Ron]

I have used AVRs for around eight years as my workhorse processor. As
long as the application could be served by my task based non-preemptive
operating system, this was the chip I used. Recently, however, I had a
couple of projects that, although their specification required a
prioritised pre-emptive operating system and therefore some hardware
memory protection, they really didn't need a full-blown 32-bit
processor. 

I am finding that new project specifications are increasingly combining
complex background processing with a range of prioritised events where
response times are critical, but where, apart from the requirement for
preemption, an 8-bit processor would be quite adequate. For those
readers who have implemented a preemptive operating system (OS) on an
AVR I agree it is possible but I am philosophically against preemption
without memory protection, particularly where the customer can
subsequently add new modules to my design. Stack overflow is simply
intractable in this hardware. 

This got me thinking about what would be required for an 8-bit micro to
reliably support a pre-emptive OS. I have used the Mitsubishi M16C and,
like the old Z80, it has two sets of registers, and this provides a
simple mechanism for providing a "supervisor" mode. Looking at the AVR,
individually pushing 32 registers is hopeless. I am sure 16 registers
are enough to support a language like C, so let's split the AVR into two
banks of 16. One bank would have more hardware "privileges" than the
other and I will come to them later.

I think that in reality, the architecture of the AVR was designed for
the poor old 1200. Sometime later Atmel realised it was just a student
project without a ram-based stack and so they hacked in some additional
silicon to give it a barely useable stack pointer. So my second major
change would be to give the stack pointer the same addressing
functionality as the Z register pair, and the ability to push/pop itself
in a single instruction. Importantly, there would be two stack pointers,
one for each register bank. While on the subject of pushing and popping,
there should also be a single instruction to push the entire 16 general
registers.

So now we can quickly save state, have real stack frames, and a fast
method for switching to a "privileged" register set that automatically
has its own stack frame, all without much additional silicon. 

Now for the new stuff. What is the minimum protection required to
support a preemptive OS? For me this would be a lower boundary on the
stack frame, with an exception interrupt on an attempt to write outside
this limit. You can actually hack this structure with an old 8535, some
external memory, an address sized latch, and a similar sized comparator
on the address bus. A match produces an IRQ. Write the lower stack
boundary into the latch and voila! Not very practical but proof of
concept. In the architecture I am proposing here, the non-maskable
exception interrupt vector would be in the supervisor register space and
the exception would automatically produce a register set switch.

>From the OS's view, when it allocates a stack frame for a new process,
it would write the boundary into the process database. The boundary is
written into the hardware during the process switch along with all the
other machine state change when this process runs. A runtime exception
would allow the OS to attempt a stack size increase, copy and release
the old stack, update as necessary, and re-schedule the process which
would eventually continue as though nothing had happened. Except that it
has earned an OS demerit point and will be watched very carefully in the
future!

Of course it would be nice to have an upper stack boundary and data
space boundaries but these areas are easier to control with careful
design whereas the optimum stack size is very difficult to estimate in a
complex asynchronous system and stack overflow is the most common crash
cause in typical preemptive systems without hardware protection. 

Besides, there are plenty of micros available with a complete MMU when
this is critical. What I am proposing here is the most important new
piece of hardware that could be added to 8-bit micros that would allow
their continued use in a world increasingly needing preemptive
solutions.

Ron Kreymborg