sward@cfa.HARVARD.EDU (Steve Ward) (05/14/89)
With respect to my posting which inquired about the config.sys argument "STACKS=N,X" sorry about two different versions of the message being posted inadvertantly.....With respect to the inquiry itself, I have ferreted out an explanation with debug and a little disassembly, though my 8086 assembly language familiarity is pretty basic. For this reason I present what I believe are the facts and hope that others will fill in the details and correct any errors. It appears that indeed, the "STACKS=N,X" arguments to config.sys result in the assignment of hardware interrupt stacks where n=number of stacks and x=size of stack. Also, it appears that only the external hardware interrupts (NMI and IRQ 0-7) are affected. Also, this is accomplished by "hardware interrupt vector chaining." I have checked both the generic Microsoft MS-DOS 3.3 and PC-DOS 3.3 and they both behave identically. What happens is that MS-DOS configures itself at load time, among other load/initialize details, when it sees a STACKS=N,X argument to config.sys it assigns a hardware interrupt stack to each hardware interrupt vector service routine. It does this by saving the hardware interrupt vector that the BIOS had set up, replaces it with a vector to the MS-DOS routine that sets up the desired stack, then this MS-DOS routine pushes flags onto the stack and does a FAR CALL to the original interrupt service routine. By pushing flags before the CALL the stack will be in alignment when the IRET is executed in the service routine. The service routine returns to the calling MS-DOS routine where the machine state is properly restored and another IRET instruction is executed. In this way MS-DOS intercepts the hardware interrupt to provide a stack to the interrupt service routine. In an AT or 386 this is unavoidable in that my manuals claim that the defalut (no STACKS=N,X in config.sys) is to intercept the external hardware interrupts to provide a single stack for each interrupt vector. In an XT the default is no hardware interrupt stack provision, so in an XT this feature is optional. The interception code supports a pool of interrupt stacks so that as long as their is an available interrupt stack frame in the pool a new stack frame will be assigned for each new interrupt, even for the same hardware interrupt level. Of course, most PC interrupt service code is written so that during execution of the service routine only interrupts of higher priority can cause further interrupts. As long as this is true there is no need to go beyond STACKS=9,X but if an interrupt service routine enables interrupts, including its own level/priority, then there may be reason to increase the interrupt stack pool. I don't know what happens if an interrupt occurs and there are no more interrupt stack frames to allocate. Is an error issued-I doubt it. Is the current stack used-I would guess so, in which case as long as it was deep enough all would be okay, and if not, the system would probably crash. Any comments here? I wonder about the utility of this feature. It has its appeal but I don't like the idea of the AT and 386 making its use mandatory. Of course, it can be circumvented by seizing control of the hardware interrupt vectors after MS-DOS is loaded but BIOS extension EPROM's do their initialization prior to MS-DOS loading and so can do nothing to circumvent this feature except on an XT. This feature seems to make it interesting for BIOS extension EPROM's that have external hardware interrupt service routines. Clearly MS-DOS runtime (TSR's, MS-DOS programs) code that contains external hardware interrupt service routines can choose to use this MS-DOS stacks feature or ignore it. In that vein, do any of the MS-DOS interrupt vector install/remove support functions support this stacks feature by actually placing the vector in the chaining save area rather than into the vector itself? This would so that the MS-DOS stacks code still intercepts the hardware vector. Steve W. ward@cfa.harvard.edu
jvte@euraiv1.uucp (Jan van 't Ent) (05/22/89)
sward@cfa.HARVARD.EDU (Steve Ward) writes: >In an AT or 386 this is unavoidable in that my manuals claim that >the defalut (no STACKS=N,X in config.sys) is to intercept the external >hardware interrupts to provide a single stack for each interrupt >vector. In an XT the default is no hardware interrupt stack >provision, so in an XT this feature is optional. You could try using STACKS=0,0 though I don't know exactly what results will be (and some reports say that not all MsDos versions allow this). <Jan>