jca@hou2f.UUCP (J.ANTROSIGLIO) (05/28/86)
I have an interrupt service routine which is linked with my Microsoft 'C' application program. When the program is started it installs the pointer to the service routine in the vector table. As soon as the first interrupt is generated I get a stack overflow message on the screen and the system hangs. If I disable the external interrupt source everything works fine. Sounds like a problem in the interrupt service routine. History: This service routine is written in assembler and works fine when linked with compiled MS basic. To link with 'C' I changed it to assume the _TEXT segment for code and DGROUP for data, bss, and stack, as per the Microsoft 'C' manual. I allocated more stack during the linking phase but that didn't seem to help. One thing that I'm doing that may be a problem is the way I install the interrupt vector. Rather than using the get/set interrupt vector functions in DOS I just poke the segment and offset into the vector page at address 0x2c (IRQ3). I don't understand why this should cause a problem. I did it this way with the compiled basic version. Is there anything special I need to do when installing a interrupt service routine which is used by a Microsoft 'C' program. Any comments or code examples would be welcome. Thank You, John Antrosiglio ATT-Bell Labs ihnp4!hou2f!jca
petera@utcsri.UUCP (Smith) (05/30/86)
> > > I have an interrupt service routine which is linked with > my Microsoft 'C' application program. When the program is started > it installs the pointer to the service routine in the vector table. > As soon as the first interrupt is generated I get a stack overflow > message on the screen and the system hangs. If I disable the external > interrupt source everything works fine. Sounds like a problem in the > interrupt service routine. > > History: > This service routine is written in assembler and works fine when > linked with compiled MS basic. To link with 'C' I changed it > to assume the _TEXT segment for code and DGROUP for data, bss, and > stack, as per the Microsoft 'C' manual. I allocated more stack during > the linking phase but that didn't seem to help. > > One thing that I'm doing that may be a problem is the way I > install the interrupt vector. Rather than using the get/set interrupt > vector functions in DOS I just poke the segment and offset into the > vector page at address 0x2c (IRQ3). I don't understand why this should > cause a problem. I did it this way with the compiled basic version. > > > Is there anything special I need to do when installing a > interrupt service routine which is used by a Microsoft 'C' > program. Any comments or code examples would be welcome. > > > Thank You, > > John Antrosiglio > ATT-Bell Labs > ihnp4!hou2f!jca Re: Installing an interrupt service routine in C. Since you are getting a stack overflow what is probably happening is that the Lattice/Microsoft Compiler is generating stack checking code. Ie every time a function is entered it compares the stack top pointer with some maximum value, if it is greater it then aborts with a 'stack overflow' message. The reason you are getting this is due to the fact that the stack at the time of the interrupt will not be the same one that the C program is using, the segment may even be different. It is ok to use this stack, but only for about 20 or 30 pushes. In any case the C stack checking code will most of the time catch the fact that the stack top is wrong. There are two solutions. 1: Disable the stack checking code when you compile this module or 2: Alter the stack overflow trap routine to do nothing. Note that when you trap the interrupt in C you cannot do any calls to read/write/malloc etc because they all result in an INT which will when it returns, prematurely switch on your interrupts. Peter Ashwood-Smith University Of Toronto.
jeff@turtlevax.UUCP (Jeff Doughty) (05/30/86)
> I have an interrupt service routine which is linked with > my Microsoft 'C' application program. When the program is started > it installs the pointer to the service routine in the vector table. > As soon as the first interrupt is generated I get a stack overflow > message on the screen and the system hangs. If I disable the external > interrupt source everything works fine. Sounds like a problem in the > interrupt service routine. > I had a similar problem a few years ago with Lattice C. I don't know if it applies to you, and I'm real fuzzy about the details, but here goes. I wrote a short interrupt service routine in assembler which did a little setup (including resetting the segment registers) and then called a Lattice C routine. On the first interrupt I also got a stack overflow message. It turned out that the stack overflow checking code generated by the C compiler was the problem. When I recompiled the routine with the compiler flag to leave out overflow checking, it worked fine. (Here comes the fuzzy part.) It turned out that the overflow checking code compared the SP against some global value. Since I had reset the segment registers, I was accessing the wrong value. Hope this is of some help. Jeff Doughty Cimlinc, Inc.
kevin@trsvax (05/31/86)
> I have an interrupt service routine which is linked with > my Microsoft 'C' application program. When the program is started > it installs the pointer to the service routine in the vector table. > As soon as the first interrupt is generated I get a stack overflow > message on the screen and the system hangs. If I disable the external > interrupt source everything works fine. Sounds like a problem in the > interrupt service routine. Try compiling the 'C' module with stack probes removed (the /Gs option, I think). The stack pointer as MSC is comparing it is probably not what is actually passed by the interrupt service routine. You might also have problems with what DS is set to, depending on what model you're using. I had a similar problem doing a routine run off the timer interrupt once, and using /Gs cleared it up. good luck! kevin dack {known world}!ctvax!trsvax!kevin
brad@looking.UUCP (Brad Templeton) (05/31/86)
>> >> One thing that I'm doing that may be a problem is the way I >> install the interrupt vector. Rather than using the get/set interrupt >> vector functions in DOS I just poke the segment and offset into the >> vector page at address 0x2c (IRQ3). I don't understand why this should >> cause a problem. I did it this way with the compiled basic version. ARRGGH. DON'T DO THIS. DON'T DO THIS. DON'T DO THIS DON'T DO THIS. DON'T DO THIS. DON'T DO THIS DON'T DO THIS. DON'T DO THIS. DON'T DO THIS DON'T DO THIS. DON'T DO THIS. DON'T DO THIS DON'T DO THIS. DON'T DO THIS. DON'T DO THIS Every time somebody does this they make another program that won't run with a) A new 286 or 386 protected mode DOS b) Dos emulators that run under other operating systems c) Extended versions of DOS produced by other companies. You may not care if your program runs, but every program like this discourages OS writers from attempting any of the above products, and leaves the rest of the world with the same old DOS. When you need a function (such as fast screen i/o) that DOS doesn't provide, you may have no choice but to bypass the OS. But when the OS already has a call to do the thing you want, there's rarely an excuse. -- Brad Templeton, Looking Glass Software Ltd. - Waterloo, Ontario 519/884-7473