Re: Fwd: newb question : list of elligible computers to debian-68k
On Thu, 23 Oct 2008, Michael Schmitz wrote:
> > > > No idea what to do about (1). Since I don't understand the
> > > > implications of "overlapped execution", I can't hazard a guess as
> > > > to whether this kind of fix is even theoretically feasible.
> > >
> > > What this means is that one instruction is in the process of being
> > > executed while another one is being loaded and decoded at the same
> > > time.
> >
> > That's what I thought.
> >
> > > Loading it would trigger the page fault while executing of the
> > > previous one had triggered the unimplemented instruction exception
> > > just previously. Only guessing here...
> >
> > Thing is, we have to know exactly what the saved PC will be when
> > either,
> >
> > a. ATC fault at unimplemented fpu op and bug may or may not take
> > effect
>
> Bug takes effect - the PC is what we need.
>
> Bug does not take effect - the PC is that of the instruction causing the
> page fault, i.e. identical to the fault address (ISTR instruction
> execution always completes before trap or page fault in the normal case,
It depends on the exception priority (given in the table I mentioned).
> and the trap must've completed otherwise we'd see the PC point to the
> FPU opcode)
>
> > b. ATC fault with no unimplemented fpu op
I meant, "ATC fault with no unimplemented fpu op being executed".
>
> PC is equal to fault address.
Which may be of no use to us, depending on "overlapped execution"!
The saved PC for an ATC fault like (a) and one like (b) could both point
to an unimplemented FP op, but only in the case of (a) is that useful. In
the case of (b), overlapped execution (or pre-fetch?) implies that the
fault address _may_ be an instuction that will generate an unimplemented
FPU op later on, when it is executed. You can't always tell (a) and (b)
apart! (At least not from the bits of the programmers manual that I looked
at.)
> > The point I was trying to make is that only for (a) is the saved PC
> > determined (that's what the docs I quoted tell me, anyway). Which
> > means, the fault handler can't tell (a) and (b) apart.
>
> It all hinges on the behavior in the case where the bug isn't properly
> triggered.
I still think that the vagueness of (a) is a secondary concern.
> If the PC points to the same page as the fault address in that case,
> we're fine, i.e.
>
> if (page_of(PC) < page_of(fault_addr) && is_fpu_op(PC)
> need_fixup;
>
> would be possible.
>
> Your test kernel would be the ideal candidate to test whether there ever
> is a case where the F-line trap was taken correctly, yet the PC still
> reported on the wrong page afterwards.
Such a bug is not mentioned in the errata...
Finn
>
> Michael
>
>
>
Reply to: