[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Fwd: newb question : list of elligible computers to debian-68k



Hi,

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.)

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?

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.

I'll have to think on that some more.

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...

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?

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.

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: