On Mon, Dec 3, 2012 at 8:00 AM, Olof Kindgren <[email protected]> wrote: > 2012/12/3 Peter Gavin <[email protected]>: >> On Sun, Dec 2, 2012 at 7:44 PM, Julius Baxter <[email protected]> >> wrote: >>> >>> So, please, go to that wiki page, submit a proposal, we can discuss >>> it, but it's not going into this round of the architecture spec. There >>> will be another opportunity, certainly. >> >> >> I've come to agree with Matthew that they should raise exceptions, but I'm >> content with your earlier suggestion that they be marked as having an >> implementation dependent effect so we can get the spec out. I looked >> through the spec, and I believe that l.m[ft]spr with privileged addresses >> and l.rfe are the only instructions that could be problematic for >> virtualization in user mode. >> >> -Pete >> >> _______________________________________________ >> OpenRISC mailing list >> [email protected] >> http://lists.openrisc.net/listinfo/openrisc >> > > My vote goes for proper separation of user mode and supervisor mode. > As we want to future-proof these things, I think it's a bad idea to > take shortcuts regarding the privileged instructions.
Hej Olof, This isn't a shortcut, it's just something to say what the behaviour is, it's not locked in forever. But I understand there's the potential for it to be annoying if it's defined in one way in the earlier spec and a different, incompatible way in a later version. So, I'm going to leave it in an unfinished state, like other things (instruction classes are another big issue we haven't gotten to the bottom of, and that is a far more important and practical issue than this hypervisor stuff.) > > On the other hand I can also see the need to push out a 1.0 spec. One > of the things that we really need in the spec is the updated revision > registers. That feature will allow us to break backwards compatibility > easier in the future as we can ask the hardware what version of the > arch spec we are implementing. > > With this said, would it be possible to put out a new version of the > arch spec with just the versioning stuff (plus all the things that we > have finished discussing) and put the rest of the things on hold for a > while? I fear that the number of proposed changes are growing too much > for a single update That's basically what we're doing. I'm adding the things which we have known about and discussed for months. The most recent development which is going in is the overflow exception behaviour, but this has been discussed for months and I'm convinced we've got a solution. Beyond that, as I mentioned, we've still got a lot of big issues to solve in the spec, like the instruction classes, instructions for atomic memory access, performance counters, sleep/halt instructions. etc. So there's definitely things we've not solved yet, but we should run with what we have, which you appear to agree to. Cheers Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
