Re: [Simulavr-devel] two things

[Theodore A. Roth]

On Thu, 20 Nov 2003, John Regehr wrote:

> > > 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.
>
> Yeah.  I think that the only right way to do this is to wait until the
> global enable bit is set, and then fire in priority order the pending
> interrupts whose individual enable bits are set.

Agreed.

> Checking the individual bits before posting the interrupt isn't quite
> right.

Isn't it true that the irq should not even be put into the pending list
unless the irq enable bit is set? I thought that was one of the
conditions that must be met before an irq can be raised. Maybe I'm
missing something...

>
> > 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().
>
> Ok, cool.  That's what I get for not reading the code carefully enough!

I'm never against people questioning my code. I forces me to take
another look at it and some times they are right. ;-)

Ted Roth