Date: Thu, 27 Apr 95 16:38 MDT
From: mat AT ardi DOT com (Mat Hostetter)
To: dgymer AT gdcarc DOT co DOT uk
Subject: Re: Chaining real-mode interrupts
References: <9504270959 DOT AA28138 AT gdcarc DOT co DOT uk>
Cc: bdavidson AT ra DOT isisnet DOT com, djgpp AT sun DOT soe DOT clarkson DOT edu

>>>>> "Dave" == Dave Gymer <dgymer AT gdcarc DOT co DOT uk> writes:

    Dave> I seem to remember that GCC can collect up stack cleanups
    Dave> and do them in a big chunk after a while, which is normally
    Dave> a slight speed win. There's probably a way to fix it using
    Dave> the "volatile" keyword, eg. declare your handler as

    Dave> 	volatile void my_handler() { ... }

    Dave> but I perhaps someone with more in-depth knowledge of how
    Dave> GCC deals with this could confirm or correct that?

What you are talking about is the "-fno-defer-pop" flag.  But you
almost never want that...letting gcc accrue junk on the stack is
faster.  It all gets cleaned up on function exit.

If you think gcc's assembly output is wrong, post it!  I've responded
to a zillion messages where people have complained of a possible gcc
problem but never provided enough information.

I've forgotten the original thread, but basically V1.x has massive
problems with interrupts.  I have spent many, many hours dealing with
V1.x interrupt problems, and eventually we (ARDI) wrote our own
interrupt handling stubs in assembly to set up the stack, etc.

Fortunately, interrupts appear to be rock-solid under djgpp V2 if you
follow the rules (lock down all memory touched at interrupt time,
remember that %ss != %ds during interrupt time, etc.)

-Mat