Sender: dgymer <dgymer AT sun2 DOT gdcarc DOT co DOT uk>
From: Dave Gymer <dgymer AT gdcarc DOT co DOT uk>
Organization: GDCARC Ltd
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Date: Thu, 27 Apr 1995 10:01:46 +0000
Subject: Re: Chaining real-mode interrupts
Reply-To: dgymer AT gdcarc DOT co DOT uk

> From:          Bill Davidson <bdavidson AT ra DOT isisnet DOT com>
> More followups on the great hardware interrupt bug hunt:
[...]
> As for my own code, I tried the -S option to gcc and looked over the 
> resulting assembler (also had -O2 in there).  I noticed that in my 
> handler function, where it called memset() and where it called 
> _go32_dpmi_simulate_fcall_iret(), there was no cleaning-up of the stack 
> on return.  I confess that I am not up on 386+ assembler (I learned 8088 
> assembler then switched to C); I think the 'leave' command does the stack 
> cleanup (?), but it still looked wrong to me, especially in a handler 
> function.  So I recompiled the module without any optimization, relinked, 
> and the program ran pretty good.  The keyboard handler still seems to be 
> a problem, but at least I am getting some (unstable) results!

> Any thoughts/ideas/feedback welcome.

Sounds like GCC is optimizing the cleanup away when it shouldn't, hence 
the correct behaviour when compiling without optimization; I seem to 
remember that GCC can collect up stack cleanups and do them in a big 
chunk after a while, which is normally a slight speed win. There's 
probably a way to fix it using the "volatile" keyword, eg. declare your
handler as

	volatile void my_handler() { ... }

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

Chisa
-- Dave "Gizmo" Gymer                 Telephone +44 (0)1268 534228
--   General DataComm Advanced Research Centre Ltd, Basildon, UK
-- dgymer AT gdcarc DOT co DOT uk (preferred) or Dave DOT Gymer AT laUNChpad DOT unc DOT edu
-- http://www.mal.com/~dgymer/              dgymer AT mal9000 DOT mal DOT com