2012/4/24 Peter Gavin <[email protected]> > 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'll add 3 mode flags to gcc, -mbranch-delay, -mno-branch-delay, and > -mcompat-branch-delay. -mbranch-delay will be the default for the > or1k arch. -mno-branch-delay will be the default for the or1knd arch. > -mcompat-branch-delay will work on either arch, and will just fill > all the delay slots with nops. > > How does that sound? > > -Pete > _______________________________________________ > OpenRISC mailing list > [email protected] > http://lists.openrisc.net/listinfo/openrisc >
Hi Pete, That sounds fine with me. I guess you are talking about merging the toolchains, not RTL code, right? >From what I have understood, you have rolled your own VHDL or1k too. Do you have a feel for how much changes that would be needed to add a configurable delay slot-less option to the existing or1200 code base? -- 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
