Advertisement

Coming to terms with interrupt vectors and tables

November 01, 2006

Dan_Saks-November 01, 2006

Be careful with your lingo. Just because a lot of developers use the same terminology doesn't mean they agree on what it means.

In my last column, I explained that an interrupt vector is a memory-mapped object, which you can model using techniques similar to those you can use for other memory-mapped objects.1

That column generated more reader e-mail than I normally receive. Because a few of those messages raised valid questions about the terminology I used in my explanation, this month I'll deconstruct that terminology.

Just what is an interrupt vector?
More than one reader took issue with how I used the term interrupt vector. Here's what I wrote:

"A processor typically maps each interrupt type to a corresponding pointer in low memory. The collection of pointers for all the interrupt types is an interrupt vector. Each pointer in the vector points to the ISR for the corresponding interrupt type."

As one reader explained:

"You are confusing interrupt vector with interrupt vector table. An interrupt vector is only ONE memory address of one interrupt handler. An interrupt vector table is a group of several memory addresses."

He then cited the definition of interrupt vector (as of October 2006) from Wikipedia:2

"An interrupt vector is the memory address of an interrupt handler, or an index into an array called an interrupt vector table or dispatch table. Interrupt vector tables contain the memory addresses of interrupt handlers."

My initial reaction to reading this was mild surprise ("hmm" rather than "yikes!"). I've been speaking at the Embedded Systems Conference for 14 years. For the last five, I've delivered a number of different talks that included discussions of interrupt handling. In each talk I used the term interrupt vector as I did in my column, and no one--not one--among the hundreds of attendees questioned me on it. They certainly questioned me on other things, but not on this terminology. I expected that if anyone had an issue with my terminology, I'd have heard of it already. Hmm.

Of course, the fact that no one questioned my terminology doesn't make that terminology correct, so I decided to investigate. Wikipedia is often a good starting point for an investigation, but I don't place too much stock in what it says until I can find verification elsewhere. (For grins, google for "Wikiality." If you locate a video of Stephen Colbert's August 1, 2006 commentary on "Wikiality," watch it and grin some more.) As of this writing, the Wikipedia entry for "interrupt vector table" has a banner at the top stating "This article or section is in need of attention from an expert on the subject." The entry for "interrupt vector" has no such disclaimer, but after reading this article, maybe you'll agree it needs one, too.

I consider Jack Ganssle's and Michael Barr's Embedded Systems Dictionary to be a more reliable source.3 Here's how it defines the phrases in question:4

interrupt vector n. The address of an interrupt service routine.
USAGE: This term is sometimes used incorrectly to refer to either the interrupt type or the address of the interrupt vector.

interrupt vector table n. A table containing interrupt vectors, indexed by interrupt type, that maps interrupts and interrupt service routines. The interrupt vector table must be initialized before interrupts are enabled.

In short, the conflict is that I have been using the term "interrupt vector" to refer to a collection of pointers, while others use it to refer to one pointer. For the moment, I will relent and use their terminology.

The G&B (Ganssle and Barr) definition is close to Wikipedia's, but less equivocal. Again, G&B state simply that an interrupt vector is "the address of an interrupt service routine." Elsewhere they say that "interrupt handler" and "interrupt service routine" are equivalent, and I accept that, at least for now. Thus, G&B's definition is essentially identical to the first part of Wikipedia's, which defines an interrupt vector as "the memory address of an interrupt handler." (I'm going to omit the word "memory" so that both definitions use exactly the same phrase. Besides, what other kind of address could a handler have?)

The "or" part of Wikipedia's definition states that an interrupt vector could also be "an index into an array called an interrupt vector table." (I'm going to omit "or dispatch table" from this discussion. It has its own set of problems.) G&B's usage note suggests that this alternative is incorrect, and I agree. To be really clear about why, let's map the terms into C notation.

Mapping the terminology into code
Using either definition (G&B's or Wikipedia's), if you could declare an interrupt vector table as an object in C, it would be an array v declared as:

T v[N];
where T is the type of a single interrupt vector and N is the number of distinct interrupt types. (Here and throughout this article, "type" means "a C or C++ data type," whereas "interrupt type" means "a number associated with each interrupt.") A value i in the range from 0 to N-1, inclusive, designates a single interrupt type. As I showed in my previous column, i might be a value of an enumeration type such as:

enum interrupt_type
    {
    it_begin,
    it_reset = it_begin,
    ...,
    it_IRQ,
    it_FIQ,
    it_end
    };
In this case, N would be equal to it_end " it_begin. Whether i is an integer or an enumeration value, v[i] is an interrupt vector whose value after initialization is the address of the handler for an interrupt corresponding to interrupt type i. In my previous column, I showed that you can declare pointer_to_ISR as a pointer-to-function type using:
typedef void (*pointer_to_ISR)(void);
Type T, the type of a single interrupt vector, is equivalent to pointer_to_ISR. Using the more descriptive names, the declaration for an interrupt vector table would look like:
pointer_to_ISR
    interrupt_vector_table[it_end " it_begin];
However, for the following discussion, I will use the terser form:
T v[N];
Back to the definitions
Again, the Wikipedia definition states that an interrupt vector is "the address of an interrupt handler, or an index into an array called an interrupt vector table." This appears to say that an interrupt vector is either v[i] (a handler address), or it's just i (an array index corresponding to the interrupt type). I think the latter part (starting with "or") is incorrect, and G&B's definition backs me up.

By G&B's definition, v[i] is indeed an interrupt vector, but i isn't. G&B's usage note says that interrupt vector is "sometimes used incorrectly to refer to . . . the interrupt type"--in this case, i. The phrase "an index into an array called an interrupt vector table" sure sounds like "interrupt type" to me. I read the latter part of Wikipedia's definition to suggest that interrupt vector and interrupt type are synonyms, and they aren't.

G&B's usage note also says that interrupt vector is "sometimes used incorrectly to refer to . . . the address of the interrupt vector"--that is, &v[i]. I've never seen this usage, but I agree that it would be wrong, too.

My assessment is that the second part of Wikipedia's definition is incorrect, but before discarding it, let's take one more look. This may be a bit of a reach, but bear with me.

I have on occasions heard people mistakenly refer to an array element selected by indexing as an "index into an array." If the author(s) of the Wikipedia article made this mistake, their definition wouldn't be wrong, just worded poorly. Maybe they meant that an interrupt vector is "the address of an interrupt handler, or an element in an array called an interrupt vector table." This "corrected" definition doesn't run afoul of G&B's usage note. And, it seems to make perfect sense, that is, until you think about what it really means.

Once again, my formal model declares an interrupt vector table v as an array:

T v[N];

where T is a pointer-to-function type. The first part of my "corrected" Wikipedia definition (along with G&B) says that an interrupt vector is "the address of an interrupt handler." Using the formal model, an interrupt handler is a value of type T. The second part of Wikipedia's definition says that an interrupt vector could also be "an element in an array called an interrupt vector table." More formally, it says that an interrupt vector could be v[i] for some 0 i < N. But each v[i] is just a particular value of type T, so the "corrected" definition for interrupt vector is equivalent to "any value of type T, or a value of type T that's an element of v." Seen this way, the second part of the "corrected" definition ("or" and everything thereafter) is clearly redundant; it's just a special case of the first part.

The Wikipedia definition for "interrupt vector" is poorly worded at best. Does that mean we should just accept G&B's definition? Not yet. I believe it has a problem, too, though much subtler than Wikipedia's. It's a problem of omission rather than commission.

Are all handler addresses interrupt vectors?
Let's expand the formal model just a little. Suppose function h defined as:

void __interrupt h(void)
    {
    ...
    }
is a handler for interrupts of type i. As I explained in my previous column, you can place the address of h into the interrupt vector for type i using:
v[i] = h;
When it appears in an expression, h is an expression whose type is pointer-to-function. You don't need to write &h. In C and C++, expressions h and &h yield the same result: the address of the handler function named h. Remember, according to G&B's definition (and the correct part of Wikipedia's definition), an interrupt vector is "the address of an interrupt handler." Well, after this assignment, v[i] is clearly an interrupt vector--its value is the address of an interrupt handler. But then so is the expression h--its value is also the address of an interrupt handler. My problem with this definition is that, while I believe most knowledgeable embedded systems developers would say that v[i] is an interrupt vector, they would say that h isn't. And they'd be right. As another example, suppose you declared p as a variable of pointer-to-function type T, as in:
T p;
Then you could assign:
p = h;
v[i] = p;

Here, p is an object whose value is the address of an interrupt handler. Would you say that p is an interrupt vector? I wouldn't. But G&B's definition says p is.

The reason that v[i] is an interrupt vector, but h and p are not, is that each v[i] is a special memory-mapped object that the processor and/or interrupt controller uses to initiate a handler to respond to the interrupt associated with interrupt type i. Despite the popular definitions, I don't believe ordinary pointer expressions such as h and p are ever interrupt vectors. Each v[i] is an interrupt vector precisely because it means something special to the underlying hardware.

In fact, I'd claim that each v[i] is an interrupt vector even before it's properly initialized. It's v[i]'s role as part of the interrupt dispatching hardware that makes it an interrupt vector, not just the fact that its value is the address of a handler.

More to come
I'm working my way toward proposing a better definition for the term interrupt vector. Along the way, I'll show why neither G&B's nor Wikipedia's definition applies to interrupt vectors as implemented in popular architectures such as the ARM or PowerPC.

I hope to propose a new definition for interrupt vector that encompasses a wider range of architectures.

Thanks to Jack Ganssle, Bill Gatliff, and Joel Saks for their help with this article.

Dan Saks is president of Saks & Associates, a C/C++ training and consulting company. For more information about Dan Saks, visit his website at www.dansaks.com. Dan also welcomes your feedback: e-mail him at dsaks@wittenberg.edu. For more information about Dan click here .

Endnotes:
1. Saks, Dan. "Modeling interrupt vectors," Embedded Systems Design, September 2006, page 11.
Back

2. http://en.wikipedia.org/wiki/Interrupt_vector
Back

3. Ganssle, Jack and Michael Barr. Embedded Systems Dictionary. CMP Books, 2003.
Back

4. You can find these and other excerpts from the Embedded Systems Dictionary online on Michael Barr's website at www.netrino.com/Publications/Glossary.
Back

Reader Response


I'd agree that an interrupt vector is a pointer to the address of an interrupt service routine, where such a pointer is located at a pre-determined address (this makes it a vector not just a pointer). In some processors the location is hardwired in others it is set in software. The definition of interrupt handler is ambiguous--it can be just the individual interrupt service routine or it can be the code that is called by every interrupt, which determines which interrupt has been triggered and calls the appropriate service routine (using the interrupt vector!)

- stefano zammattio
High Wycombe, UK


You say "The "or" part of Wikipedia's definition states that an interrupt vector could also be "an index into an array called an interrupt vector table." (I'm going to omit "or dispatch table" from this discussion. It has its own set of problems.) G&B's usage note suggests that this alternative is incorrect, and I agree. " I disagree.

When designing processor boards back in the 1980s I used the 8086, '186 and '386 together with the 8259 interrupt controller and 8274 serial port controller devices. Both of these devices provided vectored interrupt support by providing the processor with an interrupt vector on the processor bus. This value was the index into the table of addresses held in the interrupt vector table. The data sheet for the 8259 device states that "When an interrupt is acknowledged the highest priority request is determined and its vector placed on the bus."

"When I use a word," Humpty Dumpty said, in rather a scornful tone, "it means just what I choose it to mean -- neither more nor less."

- Ian Okey
Satamatics Limited
Ledbury, UK


I cannot believe that you devoted more than seven pages of your magazine to such a frivolous topic. Who really cares if it is called interrupt vector or interrupt vector table? Any software engineer worth his/her weight in bits understands what is being referred to when either of these terms is used. My software will be no better nor no worse if I use either of these terms incorrectly. Please try to devote your magazine to more meaningful matter that can benefit the embedded programmer.

-Jeff Pohl
Hixson, TN


Loading comments...