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. Le draft est mort! Vive Le 1.0 spec! -- Olof Kindgren ______________________________________________ ORSoC Website: www.orsoc.se Email: [email protected] ______________________________________________ FPGA, ASIC, DSP - embedded SoC design _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
