2012/4/24 Peter Gavin <[email protected]> > On 04/24/2012 04:50 PM, Jonas Bonn wrote: > >> On Tue, 2012-04-24 at 15:35 +0200, Peter Gavin wrote: >> >>> On Mon, Apr 23, 2012 at 11:19 AM, Julius Baxter<[email protected]> >>> wrote: >>> >>>> Sure (by the way I would hope we can maintain a single compiler port >>>> and just pass a -mno-delay-slots or something, which should have a >>>> multilib option) but I'm just saying we would also need to have it >>>> detectable by software. >>>> >>> Ok, so I'm going merge my no-delay-slot version with the main version. >>> I previously had it completely separate from the regular or1k code. >>> >>> Right now my plan is to add another bit called ND to the SR register. >>> I suppose bit 17 isn't currently taken, so I'll use that one. SR[ND] >>> will be zero for cores like the OR1200 that have a delay slot, and 1 >>> for my core that doesn't have it. >>> >> I don't see why this is needed. I need to know this at compile time... >> why do I need to know it at runtime? >> > > True, but it's simple enough to add (it's just hard wired to either 0 or > 1). > > Call it or2k and add -mcpu={or1k|or2k} flag. Then make main >> architecture 'openrisc' with: >> >> openrisc defaults to -mcompat-branch-delay >> or1k defaults to -mbranch-delay >> or2k defaults to -mno-branch-delay >> >> I'm not sure that this is what's wanted by the group, and I'm not sure > or2k is planned to be compatible with or1k in any significant way. > > -Pete > > ______________________________**_________________ > OpenRISC mailing list > [email protected] > http://lists.openrisc.net/**listinfo/openrisc<http://lists.openrisc.net/listinfo/openrisc> >
I have always been of the opinion that the or2k should be something radically different. Removal of the delay slot is definitely something that we should include, and has been on the or2k proposal page for a few years, but I don't think that this feature alone will justify all the effort that would come with having two RTL code bases. Maybe it's time again to start brainstorming about what features that could go into a new CPU (whether it's called or2k or something else is another issue). Everyone's been busy with fixing the existing code base and toolchains for some time, but we are in a much better position now than two years ago. ...and again.. great work Pete! -- 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
