I've been talking on IRC a little bit lately about some OR2K instruction set ideas and put together a very rough spreadsheet with a potential instruction set encoding.
https://docs.google.com/spreadsheet/pub?key=0AsQBx9Nr1WjydEtkZFZiV1JwTTExblJKM01OR25FVHc&output=html This has let me play with bit encodings and what we can fit into the 16-bit instructions. Some fundamental assumptions are that: 1) there will be mixed 16- and 32-bit instructions 2) 16 GPRs 3) maximum data width of 32-bits 4) just integer arithmetic at this stage To explain the sheet a little bit: the lighter blue cells are the 16-bit instructions, darker blue are 32-bit and the format is basically value/field (width) with the pipe symbol separating each field (X is don't care). The fundamental instruction operations are on the left-hand column (and aren't really the mnemonics.) For example, there's several encodings for each of the add operations and I'm not writing each of those down here, just thinking about how the add instructions would be encoded. 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 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 6-bit opcode field is pretty used up, but I think there's room for about 8 more. I've probably forgotten a few things for the time being, but am just throwing it out there for people to comment on. I know it's complicated and the formattings are far from neat, but I'd be curious to code it up and see how often the 32-bit instructions are used, and what we can do about that. Cheers Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
