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 /