Message-Id: <199809022352.TAA29055@delorie.com> Comments: Authenticated sender is From: "George Foot" To: Endlisnis Date: Thu, 3 Sep 1998 00:50:51 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: HW Interrupts Reply-to: mert0407 AT sable DOT ox DOT ac DOT uk CC: djgpp AT delorie DOT com Precedence: bulk On 2 Sep 98 at 18:32, Endlisnis wrote: > Eli Zaretskii wrote: > > > Also, the FAQ says that in practice it's impossible to lock all the > > > memory that an interrupt handler touches if it's written in C. Is > > > this true? > > Of course, it's true! One particularly nasty problem is that you > > cannot lock the stack from a C function, so automatic variables cannot > > be locked. Locking the code of a C function is also hard (how do you > > know the size of the code of a function?). A trick is widely used to > > work around this, but it isn't guaranteed to work with all versions of > > the compiler and with all possible combinations of optimization > > options. > You could use 'static' variables instead of automatic ones. Then you can > lock the data. Also, you could set up your own stack. Actually, why can't > you lock the stack? Just find the address, and lock it? I think you could lock the whole stack, but you couldn't just lock the bit that this function is going to use because which bit it uses depends upon the stack state at the time of the call. There's still the problem of how to lock the code though; again you could lock the entire program's code, but if you want to lock just one function then you have to use tricks. I think Eli was referring to the method Allegro uses -- it defines an empty function after each function that will need locking, then locks all the memory between the function's entry point and the empty function (which is assumed to follow the main funtion in memory). -- george DOT foot AT merton DOT oxford DOT ac DOT uk