On 6/16/2013 4:38 AM, Mark Cave-Ayland wrote:
On 15/06/13 18:50, Bob Breuer wrote:
I'm aiming for a cpeek that catches the data faults on sparc32, so I've coded up the attached test code.
<snip>
Got some good suggestions, thanks guys. So I need to read the fault status register to clear it before the OS boots, and may as well use the status itself as the flag to indicate if a fault happened. Also the interrupt handler I had posted is overkill, so I'll narrow the focus.
I took a peek at the OpenBOOT source code to see what that does, and it seems that under the hood it is based on a trap handling solution. The key is newguarded-execute which on SPARC64 does the following:
Save the current contents of traps 30, 1f, 32 and 34 0x30 = Data Access Exception 0x1f = Level 15 interrupt 0x32 = Data Access Error 0x34 = Unaligned Access Error
Invoke the Forth word, throwing an a Forth exception upon error
Restore the contents of the above traps
From the SPARCv8 manual we could say that these map to the following SPARC32 traps:
- 0x09 Data Access Exception
- 0x1f Level 15 interrupt
- 0x29 Data Access Error
- 0x07 Unaligned Access Error
So I fired up my SS-20 and did a little poking around to see how the SuperSparc-II behaves here. * page not mapped: read/write = Data Access Exception * sbus timeout: read = Data Access Exception, write = Level 15 int * afterwards, SFSR will always be cleared to 0
For cpeek/cpoke, OBP will catch the Access Exception and Access Error, but it won't catch the Unaligned Access or Level 15 int.
So how about if I setup an interrupt handler that skips over the faulting instruction when a global flag is set, otherwise continues as is today. Then cpeek can become: - set skip_datafault flag - clear SFSR - chain to c@ - clear skip_datafault flag - check SFSR - if fault, fixup stack and return false, else return true
Now, I might be able to code up this cpeek version in forth, or just leave it in C?
In terms of the routine itself, have you had a look at the work I did a while back to catch the I/D-MMU miss traps on SPARC64? In particular I added SAVE_CPU_STATE(x) and RESTORE_CPU_STATE(x) macros to arch/sparc64/vectors.S that do all of the context save/restore work so that the code required to get back into C outside of this is fairly minimal (see reload_DMMU_tlb in the same file).
We can probably come back to this later, but I don't see any similar code for sparc32.
ATB,
Mark.