🚀 go-pugleaf

In article <1RcY6x#64Zq3Y=news@anise.acc.com> lars@salt.acc.com (Lars J Poulsen) writes:

>From a humble applications programmer, who occasionally has written a bit
>of kernel code: The biggest pain with an architecture that exposes too
>large a register file is saving and restoring on context switches.

It's more than a pain; it can cause a severe performance penalty in
some application domains.  This is one of the reasons I don't like
register-file machines: ALL the registers have to be saved and
restored across a full context switch, and there are an awful lot
of them.  Moreover, a hardware instruction isn't much help, since
the holdup is the actual data copy to and from memory, not the
instruction fetch.

For this reason, I think people with hard real-time applications should
look pretty carefully at context switch costs.

> While
>interrupt service routines can ignore this and store only what they
>need, context switches require storing of the entire register set.

There's another pitfall here.  Some machines use the same register
window mechanism to handle interrupts, automatically shifting to
a new set.  If the interrupt hits you at just the wrong call depth,
you get an automatic register spill.  So about one-sixth or one-fourth
of the time, it takes maybe three times as long overall to field the
interrupt and maybe thirty times as long to reach the first instruction
of the handler.  Since hard real time people care about predictability
next only to performance, this gives loads of grief.