On Sun, 2012-04-22 at 11:35 +0100, Julius Baxter wrote: > On Sun, Apr 22, 2012 at 10:20 AM, R. Diez <[email protected]> wrote: > > > >> So I've been working on a variation of OpenRISC that doesn't > >> have a branch delay slot. > > > > I would welcome getting rid of the delay slot. > > > > It is counterintuitive when you write assembly code by hand. It adds > > complication to the toolchain. We recently fixed a CPU core bug in that area > > that's been there for years. It makes you think about interesting questions > > like "will a breakpoint in the delay slot work?". > > > > Let's make it optional in the spec and be done with it. > > Big call! I am for the idea, and I hate debugging corner-cases due to > delay slots as much as anyone, but ... it's a lot of work! It > essentially means you have to re-write _all_ handcoded software and > modify models and the like. Think of our Linux port for example - you > force a re-write of all hand-coded sections. We struggle to keep our > implementations and tools and libraries maintained as it is and this > will almost double that work.
I'd reckon it's less work than you think. The Linux bits are easy to do... there's not that much assembler there. I could certainly do a macro, too, that allows you to build for either case (with or without delay slot), or for the "compatibility" mode that puts a l.nop in the delay slot. As for the rest of our libraries... it's manageable. uClibc doesn't have much assembler, newlib certainly has some but it's probably on the same order of magnitude as Linux, etc. The trickiest bit is GCC... but there it should just be matter of adding a -mcpu= tunable to get either: i) or1k mode with delays slots ii) or2k mode without delay slots (using or2k here to indicate a cpu that's essentially an or1k but without delay slots) iii) openrisc mode that's compatibile with both implementations because it sticks a l.nop in every delay slot (it's a bloated or2k binary) So, from a SW point of view, I think it's less of a headache than might be expected. BUT, the question I have is from the other side of things: what's the advantage of _not_ having a delay slot? > I reckon it's something we should do for OR2K, but is too large a > change for OR1K. I know we bandy about this OR2K thing from time to time, and it's always this _huge_ rewrite of everything. But a more incremental evolution might be better... just removing delay slots, for example, along with a couple of other small cleanups that don't mean creating a fundamentally new processor. If done right, we end up with a mostly-compatible CPU that doesn't require a massive SW rewrite, a baseline "openrisc" architecture that everyone is compatible with, but with specific implementations that you can target (and tune for) to get the most out of your system... like the x86 series of processors. What we've got today isn't that bad, and I don't see that this project has the manpower to start from scratch at this point. /Jonas _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
