1) The more GPRs the better; C-compilers love GPRs. 2) No conditional execution of instructions. Nice if you're making a small controller (or ARM7 clone), but not for a new architecture. Anything new should have the possibility to run Out-Of-Order execution, with branch prediction, and register renaming. Conditional instructions also make multiple unit implementations (i.e. multiple integer/floating point/load-store units) much more difficult.
Richard On Aug 8, 2012, at 7:09 , Stefan Kristiansson wrote: > On Tue, Aug 7, 2012 at 6:43 PM, Julius Baxter <[email protected]> wrote: >> Some fundamental assumptions are that: >> >> 1) there will be mixed 16- and 32-bit instructions > > Nice! > >> 2) 16 GPRs > > Why not 32? You are already restricting access to the lower > 8 GPRs in some instructions, so it wouldn't seem insensible > to have a set of 16 GPRs only accessible by 32-bit instructions. > >> 3) maximum data width of 32-bits >> 4) just integer arithmetic at this stage >> > ... >> >> The most important thing, I think, is to think of the conditional >> operation of the architecture. This spread sheet has just one >> proposal, which is to have a mechanism which: >> >> 1) can test individual values or compare two values (be they in >> registers or immediates) and generate a flag value, which goes into a >> GPR or SPR (or, Stefan has proposed that it only goes into a dedicated >> GPR) >> 2) conditionally perform jumps and other operations based on testing >> bits in this result flags register >> > > I think this starts to look pretty good, at least better than what we > have on or1k. > >> There's even instructions which combine the two (compare and branch in >> the single instruction). There's scope to make other instructions >> conditional based, too. >> > > The decisions here will reflect what kind of microarchitecture is intended, > a simple in order pipeline with no (or little) branch prediction can > benefit from conditional instructions, whereas a more complicated > out of order pipeline with strong branch prediction will most likely not. > > Stefan > _______________________________________________ > Openrisc mailing list > [email protected] > http://lists.opencores.org/listinfo/openrisc _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
