Browse Prior Art Database

ALLOCATION of STACK SPACE for INTERRUPT ROUTINES

IP.com Disclosure Number: IPCOM000039725D
Original Publication Date: 1987-Jul-01
Included in the Prior Art Database: 2005-Feb-01
Document File: 3 page(s) / 66K

Publishing Venue

IBM

Related People

Christopher, KW: AUTHOR [+2]

Abstract

This article describes a technique for managing memory allocation for interrupt information. In some existing programs there is an inability to accurately specify how much stack space the programs must provide for interrupt routines in systems which allow nested interrupts. This causes un (Image Omitted) predictable system failures for which the user has no remedial action except to stop using programs on a best-guess basis. The technique disclosed herein creates and manages a storage pool which is used to provide stack space for interrupt routines. Firstly, ground rules are laid for stack sizes. These rules, in conjunction with the technique of this disclosure, allow programs to be developed in isolation from each other.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 3

ALLOCATION of STACK SPACE for INTERRUPT ROUTINES

This article describes a technique for managing memory allocation for interrupt information. In some existing programs there is an inability to accurately specify how much stack space the programs must provide for interrupt routines in systems which allow nested interrupts. This causes un

(Image Omitted)

predictable system failures for which the user has no remedial action except to stop using programs on a best-guess basis. The technique disclosed herein creates and manages a storage pool which is used to provide stack space for interrupt routines. Firstly, ground rules are laid for stack sizes.

These rules, in conjunction with the technique of this disclosure, allow programs to be developed in isolation from each other. The first rule is that all stacks in a system must allow n bytes of stack space for interrupt processing. This rule is required in any case.

The present technique allows n to be much smaller than would otherwise be required for reliable operation. Specifically, n equals x times the sum of y and z, where x is the number of interrupts that could occur before the software is able to switch stacks. This usually is one or two, but it is dependent on the design of both the hardware and software. Y is the number of bytes that the hardware puts on the stack on an interrupt, and z is the number of bytes that the stack pool manager can put on the stack before switching to a new stack. The second rule is that any interrupt routine requiring more than m bytes of stack space must switch to its own stack rather than use the stack in force at the time of the interrupt. If the design of the system is such that some interrupt routines cannot switch to a separate stack, then m must be large enough for those interrupt routines. Otherwise, the value of m is arbitrary. During programming system initialization, a part of memory is reserved for the interrupt stack pool. The default size of each stack in the pool is n + m.

The user can override this value to optimize it for a particular system. The number of stacks in the pool is also user-specifiable to conserve storage in a system which will have few nested interrupts. The controls for processing the stack are initialized such that the stacks are given out in the same direction that items are added to an individual stack. This allows a stack to be extended by the next one, if necessary. If the system cannot detect stack overflow at the time it happens, the top of each stack can be initialized with an unlikely v...