On Thu, Apr 12, 2012 at 7:10 AM, Jonas Bonn <[email protected]> wrote: > On Thu, 2012-04-12 at 06:57 +0100, Julius Baxter wrote: >> On Thu, Apr 12, 2012 at 6:29 AM, Stefan Kristiansson >> <[email protected]> wrote: >> > On Thu, Apr 12, 2012 at 05:40:21AM +0100, Julius Baxter wrote: >> >> The following should implement and test the correct behaviour of the >> >> delay slot execption bit in the supervisor register in the OR1200. > >> One thing on the patch, though - do we need to be tracking DSX on >> instruction-fetch related exceptions? The _only_ case I can think of >> is if a ITLB or IPF occurs on the delay slot when that instruction >> goes over a page boundary. Is it useful to know in this case? It >> should work but I haven't tested it in the software test. >> > > Yes, we definitely need to track that case. Otherwise we need to use > some heuristics based on the value of the PC to figure out which page > needs loading... this is what we need to do today and it's ugly. >
OK, SR[DSX] for MMU-related exceptions should be accurate (DMMU tests worked) but I haven't tested it in the software included in this patch. That's a bit more tricky to write that one and won't be able to get around to it today. But I'll get around to it in the next week or so. I'd like to test it before its relied upon by the kernel port. >> Also, maybe we don't need to track DSX when doing system calls. >> They're not allowed to be in delay slots anyway, so maybe we should be >> clearing DSX on l.sys instructions? > > I think the documentation is wrong on this, too. It documents the value > of DSX when l.sys is in a delay slot, but that shouldn't be possible. I > think there's simply no need to track for this case. > I'd say that's another contradiction in our architecture spec which should be cleaned up. But it looks like we agree on the fundamental point here - SR[DSX] is meaningless when handling a system call. Cheers Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
