Mail Archives: djgpp/1999/12/19/08:49:38
> -----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
- Raw text -