On Mon, Apr 23, 2012 at 10:37 AM, Peter Gavin <[email protected]> wrote: > On Mon, Apr 23, 2012 at 10:30 AM, Julius Baxter <[email protected]> > wrote: >> 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 just curious how you intend to address code density. OpenRISC > should be similar in that respect to other RISC ISAs like MIPS or > SPARC, so I wouldn't say the code density is horrible, per se. The > only way I can think of to improve it would be to do something like > ARM Thumb, or to stray from the RISC paradigm and add more complex > operations. >
This is getting off topic a little bit but I'm thinking we should have: * both 16- and 32-bit instructions, the former hopefully making up the bulk of the code (still RISC-like instructions, just 16-bit variants for those without immediates or requiring only small immediates)) * combined compare-and-branch instructions For improved implementation, we should fix a few things that OR1K screwed up like operand encoding (for example look at split 16-bit immediates on store instructions versus the rest of the 16-bit immediate instructions.) See this (not updated for a while, but is the beginning) http://opencores.org/or2k/Instruction_set for what we've come up with so far. > I rather like the fact that the ISA is so simple, since it leads to > simple designs and makes it suitable for use in research and so on. I > don't think OpenRISC should abandon that use case. Yes, but I personally have seen OR1K get ruled out of consideration for use in ASICs due to incredibly poor code density versus ARM and MIPS. There's so much to be gained from fixing this that it can't be ignored. Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
