Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!mit-eddie!uw-beaver!cornell!rochester!pt.cs.cmu.edu!b.gp.cs.cmu.edu!Ralf.Brown@B.GP.CS.CMU.EDU From: Ralf.Brown@B.GP.CS.CMU.EDU Newsgroups: comp.sys.ibm.pc Subject: Re: What about the Turbo C compiler? Message-ID: <2301846e@ralf> Date: 11 Aug 88 12:26:38 GMT Sender: netnews@pt.cs.cmu.edu Lines: 24 In-Reply-To: <2714@mipos3.intel.com> In article <2714@mipos3.intel.com>, dbraun@cadavr.intel.com (Doug Braun ~) writes: }Not quite. The problem is that nothing sets up a stack segment }when the interrupt function is called. The problem arises whenever }the address of an automatic variable is used. In the tiny or small }models (which you need to use for interrupt procedures), it is assumed Huh? interrupt procedures work fine in all memory models (except maybe huge) }that DS = SS, so that automatics and static variables can be addressed }the same way. When the fubnction is called SS has been set to another value. }One cure is to have a static array to serve as a local stack, }and set SS to DS and SP to the top of this array before doing anything else in }the interrupt function. Even if your code does not use addresses }of automatics, library stuff might. This can be hell to debug, and It can also be a real pain to work around, as I found when using DESQview's asynchronous notification feature (which uses a FAR function, rather than an interrupt function, but still has SS != DS). -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=-=-=- Voice: (412) 268-3053 (school) ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: Ralf Brown 1:129/31 Disclaimer? I |Ducharm's Axiom: If you view your problem closely enough claimed something?| you will recognize yourself as part of the problem.