Hej från Sverige ! I now have my own little room in Uppsala, Sweden, and am enjoying being free from school and the parents’ presence while I can. On Tuesday, I’ll begin the internship I’m here to do, but in meantime I’ve got plenty of time for things like finding a bike (which is not as easy as it seems) and… studying new CPU archs ! I’ve also had a closer look at UEFI, but definitely won’t support it until I’m forced to.
This architecture’s reference manual has a quite unusual structure. Among other things, it is the first time I ever see a significant part of an architecture reference manual being about the OSs which run on top of it. This might be linked though one of Alpha’s unique features, though, which is that privileged software can reprogram a subset of the processor’s microcode, here called PALcode, and create new instructions. Still, I don’t think this could permit OSs to change something as basic as interrupt management, but still there’s nothing interesting about interrupts in the Alpha manual except in the part about specific operating systems. EDIT – Actually, it is indeed possible, though it obviously won’t do things like creating and deleting dedicated registers. My bad.
In some parts, Alpha is described as emulating a VAX (see here) as far as interrupts is concerned, which does makes sense when you realise that this architecture has been made by Digital Equipment Corporation, inventors of the VAX. In the part about the NT firmware, on the other hand, Alpha does some NT-specific stuff (setting up a standardized interrupt stack frame with NT exception codes and calling the kernel interrupt handler). So I guess what you get depends on which implementation of Alpha you’ve got at hand, since I couldn’t find a reference to how to implement interrupt handling in PALcode as a whole.
Itanium is an interesting architecture in more than a way, and even its failure could form the basis of a good course about compilers and computer architecture. Anyway, this architecture performs a bit like a mix of x86/x64 and ARM :
- It uses banked general-purpose registers, like ARM, to save time during interrupt handling. Detailed information related to the pending interrupt is also put on registers instead of a stack, like on SPARC except there’s only one set of such registers.
- All interrupts are disabled when processing one, like on x86. Like on x86, simultaneous interrupt are prioritized, but higher-priority interrupts cannot preempt lower-priority interrupts.
- Interrupts are vectored in a table with arbitrary location, like on x86. However, this time, you can know which interrupt vector has been triggered by having a look at CPU registers, like on MIPS, which simplifies single-vector operation. This trick doesn’t work with nested interrupts, though.
- The IVT does not include data structures but rather code, like on SPARC and ARM.