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
