On Sun, Apr 22, 2012 at 8:55 PM, Peter Gavin <[email protected]> wrote: > 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.
Sounds good! But it's also the ORPSoC test code (26 assembly code source files ) U-boot (probably not much), the newlib functions, and the various RTOS ports which are in play at the moment. I guess putting in the compatibility mode (l.nop in all delay slots) then it'd work. Longer term, though, we'd need to figure out a better way of handling this - introducing a dummy instruction after branch isn't the best thing to have to live with. > >> >> 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? For OR2K I'd like to see the ISA re-done from scratch. It wouldn't be just delay slot dropping, it'd be an entirely different instruction set to address the horrible code density OR1K has. Having baggage in terms of backward compatibility of ISAs will be counterproductive. I'm inclined to put in an extension or something in the OR1K spec saying that delay slots are optional and machines without delay slots should set bit X in SPR Y. What do we think? Cheers Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
