On Sun, Apr 22, 2012 at 4:05 PM, Jonas Bonn <[email protected]> wrote: > 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.
Indeed. I've already modified binutils, gcc, and the simulator to remove the delay slot. It took me only about a week, and the simulator passes all tests. I honestly don't think it would be too much work to get the linux port working. > > BUT, the question I have is from the other side of things: > what's the advantage of _not_ having a delay slot? The advantages aren't obvious for a 5 stage in-order pipeline. The advantages are tremendous when doing a pipeline more complex than that. > 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. I don't know that it's that big a deal, but I haven't been involved with OpenRISC for that long. But what I *do* know is that every architect I've spoken to that has had to deal with an ISA with delay slots has said he's wished he didn't have to deal with them. If OpenRISC wants to evolve beyond the realm of embedded cores and be used in higher performance designs, it would be best not to have delay slots. The delay slot is pretty much the only feature of the OpenRISC ISA that exposes the microarchitecture to the programmer. And practically the only architecture that a delay slot helps with is a short, in-order pipeline. Not having a delay slot makes the ISA much easier to deal with when trying to design for multiple-issue, and it doesn't help at all once the pipeline gets deeper. I really, really need an ISA without a delay slot for the work I'm doing, so I'm going to continue working on it anyway. At the moment I'm calling the architecture or1knd (for OR1K "no-delay"). Should I call it OR2K, since it seems like people want to drop the delay slot for the next version? -Pete _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
