Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!mailrus!ames!oliveb!intelca!mipos3!cadavr!dbraun From: dbraun@cadavr.intel.com (Doug Braun ~) Newsgroups: comp.sys.ibm.pc Subject: Re: What about the Turbo C compiler? Message-ID: <2714@mipos3.intel.com> Date: 11 Aug 88 00:50:53 GMT References: <371@gt-eedsp.UUCP> <5930012@hpcupt1.HP.COM> Sender: nobody@mipos3.intel.com Reply-To: dbraun@cadavr.UUCP (Doug Braun ~) Organization: Corporate CAD, INTeL Corporation, Santa Clara, CA Lines: 28 In article <5930012@hpcupt1.HP.COM> kluft@hpcupt1.HP.COM (Ian Kluft) writes: >I like one feature of TC in particular - interrupt functions. By putting >the keyword "interrupt" in a function definition, the compiler makes it >a function that can be called by a machine interrupt (i.e. it saves the >machine registers first and restores them before returning). 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 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 is not mentioned in the (otherwise good) section on assembly language and weird things in the manual. Doug Braun Intel Corp CAD 408 765-4279 / decwrl \ | hplabs | -| oliveb |- !intelca!mipos3!cadev4!dbraun | amd | \ qantel /