Re: [Simulavr-devel] two things

[Theodore A. Roth]

On Thu, 20 Nov 2003, John Regehr wrote:

> > make your change more efficient. Both changes may make the peripheral
> > specific logic simpler since it just needs to figure out if the intr should
> > be added to the pending list (although, I think that's all that it should
> > be doing now any ways).
>
> Ok, I have looked into avrcore.c a bit and I think the interrupt handling
> there is incorrect because it permits interrupts to fire whenever the
> global enable bit is set, ignoring the individual interrupt enable bits.

I think that currently the irq isn't put into the pending list unless
the specific intr enable bit is set (I may be wrong on this if the
register/memory level logic not implemented correctly). The irq is fired
off only if the conditions are met and the irq enable bit is set.

I think I see a race condition that your new idea might remove. The irq
may be added the the pending list, and then the irq enable cleared
before the irq makes it to the head of the pending list. In that case,
the irq should be removed from the pending list without vectoring to the
irq.

>
> Also, the AVR interrupt controller has a notion of priority among pending
> interrupts: it always fires the lowest numbered pending interrupt.  For
> example see pages 13-14 in the ATmega128(L) manual.  It doesn't look like
> this is supported by the interrupt logic in avrcore.c.

The priority logic is there. The pending irqs are inserted into the
pending list in sorted order. The head of the list is always the highest
priority irq (i.e. the lowest numbered irq which is also the irq with
the lowest vector address). See irq_list_add().