On 12/3/12, Olof Kindgren <[email protected]> wrote: > 2012/12/3 Julius Baxter <[email protected]>: >> 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 > > Hi Julius, > > Then you have my blessing, and also a big thanks for taking on this job. > I know it's a lot of work, but you're doing a great job of keeping it > together.
Well, wait for the version I propose we adopt for 1.0 before blessing anything :) Yes, it's a bit of work, but it had to be done, and sorry it's taking a bit longer to get out than I would have hoped - have had limited spare time over the last week, but it will be out before the end of this week. Cheers Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
