Skip to content

Interrupts on Alpha and Itanium (aka IA-64)

May 15, 2011

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.

Alpha

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

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.
About these ads

From → OS development

7 Comments
  1. HeTo permalink

    Actually, I think you can change how interrupts are handled using PALcode¹. I think the firmware used for running Windows NT actually sets it up to handle interrupts in a MIPS-like way, at least other features of the processor are set up to look like MIPS in that firmware².

    ¹ https://secure.wikimedia.org/wikipedia/en/wiki/PALcode lists interrupts as one of the things PALcode manages
    ² http://www.netbsd.org/ports/alpha/faq.html#nt-firmware

  2. Indeed, a closer look at the NT section tells me that early interrupt handling (saving CPU state on a stack, call interrupt handling function with the right parameters) is implemented in PALcode. It does not look quite like MIPS though (no dedicated CPU registers for knowing which interrupt has occured, this is encoded in the stack frame automatically generated by the CPU), and the link which you provide only mentions memory management as being MIPS-like. It looks like something specific to the NT kernel.

    Correcting the article, then…

  3. Daniel Nebdal permalink

    I know my alpha PWS is able to boot with both unix-style and NT-style PALcode – so you might want to check if the unix-styled PALcode is nicer? I don’t know how it actually switches, though I think it’s something you can do while booting an OS; probably just a case of setting a register and calling some privileged instruction.

    I’ve never handled interrupts on it, though – the lowest level I’ve been to was writing a few small test programs in assembler and linking them with libc on FreeBSD.

  4. Doesn’t unix-styled PALcode emulate a VAX, like OpenVMS’ one ? Have to check when I have my handbooks at hand, but I thought I’d read that.

  5. Daniel Nebdal permalink

    That sounds entirely plausible – I believe they made it for running Tru64 and OpenVMS, and those were ported from the VAX. (Not that OpenVMS is especially unix-like, but still.)

    And yeah, I don’t have my architecture manuals at hand either. I’m sure they’re still available on the net somewhere, but I kind of ought to be working. :)

  6. From a quick look at the manual, sounds like it’s the case, though it’s not very detailed. They refer to an IPL system very similar to the way a VAX does its thing, and interrupt vectors seem to be also set in a device-specific way.

Trackbacks & Pingbacks

  1. Happy birthday, OS|periment ! « The OS|periment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.