Re: Fwd: newb question : list of elligible computers to debian-68k
On Thu, 23 Oct 2008, Michael Schmitz wrote:
> Hi,
>
> If the fault address points to a FPU op that may throw an exception
> later on, the page will have been mapped in by that time, and that
> exception won't require a page fault anymore. So the exception should go
> through without interference by another (instruction) page fault.
>
> That assumes, of course, the instruction page fault being generated when
> attempting to fetch an instruction (masking the FPU fault in case (a)),
> and the FPU fault being generated when decoding an instruction after it
> has been fetched (no masking possible here). I.e. no FPU fault possible
> before the FPU instruction had been fetched (and the concomitant page
> fault taken).
>
> Faulty reasoning?
Not faulty reasoning, but your assumption is very specific: "the fault
address points to a FPU op that may throw an exception later on". (The
fault address is always on the new page, AFAIK, so I take it you mean
saved PC not fault address.) I think the erratum describes only that
"exception [to occur] later on".
So, let's question that assumption. What if the saved PC points to an FPU
op that is not going to throw an ATC exception later on? (From the same
table, "Unimplemented Floating-Point Instruction Exception processing
begins after memory operands are fetched".)
How does the exception handler distinguish the present ATC fault from the
other fault (that may or may not occur later on, i.e. the one in the
errata)? Beats me.
> ...So we can assume that whenever the PC and the fault address map to
> the same page, it's a normal page fault, and only if the PC maps to the
> page preceding the faulting page we'd have to check for a masked FPU
> exception?
When we lose an Unimplemented FP Instruction exception, the errata says
that the saved PC will be on the preceding page. For a normal ATC fault,
I've no idea.
> Can you run the test a fixed number ot times and count the number of
> wrong FPU results on the one hand, and the number of cases where the PC
> and the instruction fault address point to different pages on the other?
> If my theory is right, both counts should be equal.
I can't run any tests at the moment. And this one seems highly likely to
give equal counts regardless (we have the code...)
Finn
> OTOH, if it was this easy, Apple might have implemented such a hack (we
> all know they were not above this sort of hacks...).
>
> Michael
>
Reply to: