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.