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.openrisc.net/listinfo/openrisc
