[net.arch] 286 stack overflow

gordonl@microsoft.UUCP (Gordon Letwin) (09/06/85)

      From: brownc@utah-cs.UUCP (Eric C. Brown)

      At the risk of being flamed by all the 68K lovers, I must point
      out that the Intel 286 has stack overflow detection "for free"
      as part of their segment management (and may also have dedicated
      stack overflow/underflow detection); it can be used by setting
      the stack limit <64K, and when the stack overflows to 64K, you
      get an segment limit exception.

At the risk of being flamed at by all the 86 lovers, I must point out
that the 286 does have stack overflow detection iff you put the stack
in a seperate segment (a very expensive proposition if you're
programming in C), but you can't expand the stack segment when it
overflows.  Bottom line, the good news is that you can tell the stack
overflowed, the bad news is that you must now abort the program.

	Gordon Letwin

kendalla@iddic.UUCP (Kendall Auel) (09/10/85)

Gordon Letwin writes:

> [about the 80286 memory protection feature]
>
>                  ... but you can't expand the stack segment when it
> overflows.  Bottom line, the good news is that you can tell the stack
> overflowed, the bad news is that you must now abort the program.

To handle the stack overflow condition, you can simply create another stack
segment. Since Intel allows segments to overlap, it would be a good idea
to have the new segment include the first 2 or 3K words of the original
stack. This allows for addressing parameters which may have been passed
on the stack.

When the stack "underflows", the original stack segment can be brought
back in. I suppose you can call this "virtual stack management".

Question: What happens if the memory directly preceding the original
stack is already in use?  (Hint: what happens if you try, for example,
to expand a 32K segment into a 64K segment?)


Kendall Auel
Tektronix, Inc.
Graphics Workstations Division

(usual disclaimer)

dougp@ISM780.UUCP (09/12/85)

In regards to 80286 stack overflow, the problem is not in setting up a new
stack, but that there is a bug in the chip which causes register CX to be
trashed when the exception happens.  Thus you could restart the routine
after getting more stack, but *I* wouldn't trust it...

Reference: Intel TechBits Errata #MIP-51, 9 August 1985

Doug Pintar at Interactive Systems Corporation