From: "Gerald Hilderink" To: "Eli Zaretskii" Cc: Subject: RE: returning from interrupt with iret? Date: Sun, 19 Dec 1999 14:10:59 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Reply-To: djgpp AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > -----Original Message----- > From: Eli Zaretskii [mailto:eliz AT is DOT elta DOT co DOT il] > Sent: zondag 19 december 1999 9:09 > To: Gerald Hilderink > Cc: djgpp AT delorie DOT com > Subject: Re: returning from interrupt with iret? > > > > On Sat, 18 Dec 1999, Gerald Hilderink wrote: > > > I am writing a special embedded kernel that runs on > micro-controllers, DSPs > > and also the i386 processor. For the i386 processor I use the > _go32_dpmi_* > > functions in C for registering ISRs. This works fine. The kernel allows > > nested interrupts and for the last interrupt it may need to do a context > > switch (by swapping stack pointers) within an ISR and when its IRET is > > executed it should load the new Instruction Pointer for the new context. > > This is one of the things that the DPMI specification disallows: you > cannot switch application's context from within a hardware interrupt > handler. > > > This does not work with DPMI, because the *_iret_wrapper > mechanism or so is > > using the stack as well. Therefore I want to add my own inline assembler > > IRET code. Unfortunately, I can not find the information I need > to do this. > > Maybe other techniques can help me? > > Can you explain why do you need to switch context in an interrupt > handler? Can the context switch be delayed until the interrupt > handler returns? If it can, you could use the signal support > mechanism to implement the task switch. Currently the context switch is delayed until the interrupt returns. The problem with delaying interrupts is that somewhere a bit must be checked (by polling) in the code. To ensure immediate pre-emptive behaviour this must be checked frequently. I have learned that polling seems to be easy and flexible, but it is a source for complexity and error-prone. I have seen in an example for the 80188 processor that an immediate context switch with IRET is simpler and faster. Unfortunately, the code was written for the segmented non-flat memory model. I am using djgpp and dpmi because I want to use the i386 flat memory model. I realize that this is very difficult with dpmi :-(. The interrupt manager I have implemented is an ISR that is registered to an interrupt (with *_go32_dpmi* functions). On the occurrence of an interrupt, the manager executes all (or some) ISRs that are registered to the manager – allowing shared interrupts. After the isr-methods have been invoked and a higher priority process (thread) has been restored back to the ready queue, a context switch to the highest priority process (thread) must be performed. The manager also allows nested interrupts. This way of context switching by the interrupt return provides immediate pre-emptive behaviour. I don't know how I can do this with the signal support mechanism? For this project, I try to avoid using dpmi functions or POSIX functions as much as possible. The kernel must be portable to other platforms. The kernel I am writing is a special kernel created for the CSP paradigm. CSP stands for Communicating Sequential Process, which is a formal theory for describing and verifying the behaviour of concurrent systems. CSP defines an excellent (higher-level) concurrent programming model (e.g. occam, Ada, ParC, HandelC), because it is easy and reliable, but unfortunately not many people know this paradigm. CSP defines clear and fundamental synchronization constructs in terms of communication events (channels) and processes. These constructs are basically non-polling constructs. There are no semaphores, wait/signals or monitors. The interrupt mechanism as described above is part of external communication events. It performs asynchronous events on channel communication. Therefore the context switch call should be kept within the channel objects. Hmm, maybe for this problem polling a semaphore would still be a solution after all. Currently, the semaphore is polled outside the channel - it's more like a hack. When I can keep this polling inside the channel then it is still non-polling outside the channel :-). This can be kept simple.... Thanks, Gerald Hilderink