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 reckon it's something we should do for OR2K, but is too large a change for OR1K. > > Compatibility with old CPU cores can be easily achieved with a flag in GCC > that adds an l.nop after every jump. The GNU assembler could also optionally > inject an l.nop automatically after every jump. Maybe only the assembler > needs the flag, as I think that GCC starts the assembler every time anyway. That's just throwing away the baby with the bathwater, though. We do get performance gains by having a delay slot in a 5-stage pipeline, and the compiler knows how to achieve that, so I don't think it should be disabled. But, as I mentioned above, it's a large change and who's going to do the work to implement and maintain it? I reckon you're better off forging on with OR2K if OR1K's delay slot stuff puts you off so much. Cheers Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
