No, it makes perfect sense, you just lack the breadth of experience with different processor architectures.
This particular processor architecture used register windows and had an ABI tailored to them. Essentially the physical registers of the machine become the top of the stack and only a portion of them are visible to the code at any one time. When a function makes a call or a return, the window is adjusted appropriately. The window is usually adjusted so that some old and new registers overlap. This allows a place to pass parameters for free. After a series of successive calls or returns, it may be necessary to copy registers to/from the real stack in memory, because of register underflow or overflow (you have run out of registers to slide the window down or up). In this case, the processor raises a window exception and an exception handler (essentially, an ISR) makes the appropriate copying and adjustment.
In this architecture, it was possible to set interrupt priorities higher than the window exception handlers, hence, there was no easy way for a higher priority interrupt handler to know the state of the stack/windows and adjust appropriately. Moreover, even if such an handler simply saved away all the state, it would still need to set up its own stack and that stack would have to follow a different calling convention, since the window exceptions will not fire inside the higher priority ISR.
This scheme may sound pretty bad to you, but it represents an interesting tradeoff. Because of windowing and the fact that most programs show good "call stack locality," register windowing with overlap is a strong overall performance win, at the expense of somewhat unpredictable call/ret performance (which is why higher than window exception ISRs are allowed) and the unfortunate aspect of ISRs that can't respect the C ABI.
It's a successful but "stealth" architecture, often used in processors that are deeply embedded and not typically exposed to system programmers. They have shipped billions of cores, most as DSPs for video and audio, and for higher end baseband processors.
-- dave j
- our architecture had an unfortunate quirk in that ISRs attached to interrupts above a certain priority level could not be written in C; They had to be in assembler,
That makes zero sense, as the machine has no way of knowing how the binary code it executes is generated from assembler, C, or some other languages.