RISC

/prog/, I'm working on a RISC instruction set that is more RISC than any RISC out there. I've devised an instruction format, plus fifteen core instructions that should suffice for any programming out there. The instruction format, instruction forms, and instructions can be found here:

http://jsbin.com/ekuwap

Any comments or suggestions?

In the 32-bit version you could just OR or AND the register with itself into a new register, but since you decided to switch to 16-bit two-operand instructions, a register-register move should be added so you can fit the equivalent to a three-operand operation into 32 bits.

NOP could be removed because you can OR a register with itself for the same effect. On MIPS, NOP is sll $0, $0, 0 (4 bytes). On x86, it's XCHG AX, AX (1 byte). Some other architectures use "branch never" or a "zero register" for this. You'd only need a dedicated NOP if you're using variable-length instructions and it's impossible to make an instruction that does nothing in the minimal instruction length.

NOT could be replaced by a two-operand "move complemented" or a NOR or NAND (NOT is just doing them on a register with itself), or you can make the immediate specify one of 32 possible one-operand ALU functions or be some sort of mask for altering individual bytes in the register. There are all sorts of ideas, but it's pretty inefficient to just leave 5 unused bits.

Another issue I see is immediate values. Using a 16-bit instruction to load a 4-bit immediate is terribly inefficient. It wouldn't be so bad if you were trying to make an esoteric language that's designed to be hard to program, but for a practical CPU, you need better ways to load immediates.

Since all jumps are based on registers, the system of loading immediates would affect jumps too. You should also have a "jump and link" or "call" that saves the return address in a register before making a jump in order to call subroutines. You could even use the spare bit in j and use a special register for return (like $31 in MIPS). But if you don't care about practicality or position-independent code, you could save the return address manually by loading immediate values into a register.

>>52
MIPS manual:
The NOP instruction is actually encoded as an all-zero instruction. MIPS processors special-case this encoding as performing no operation, and optimize execution of the instruction. In addition, SSNOP instruction, takes up one issue cycle on any processor, including super-scalar implementations of the architecture.
ALPHA reference manual:
Implementations are free to optimize these into no
action and zero execution cycles.

MIPS's dedicated NOP (SSNOP) is for filling coprocessor or FPU delay slots. Nearly all RISCs and some CISCs use NOP as a synonym for some other do-nothing instruction and then special-case it in the hardware since they know there is no other reason for a programmer to use that instruction.

The all-zero MIPS NOP is actually sll $0, $0, 0. PowerPC (ori r0,r0,0), ALPHA (LDQ_U R31,0(Rx) for "UNOP", BIS R31,R31,R31 for "NOP", and CPYS F31,F31,F31 for "FNOP"), SPARC (sethi 0,%g0), ARM (MOV r0,r0) and S/360 (BC 0, "branch never") are other architectures that do similar things as MIPS and x86 regarding NOPs.

RISC design includes "synthetic instructions" which are practical because of the fixed-length instructions. In something like 68k there is both CLR.L and MOVE.L because instructions are variable length. In RISCs, there's no point in making a separate CLR instruction because it would be the same size and speed as XORing the register with itself or loading immediate 0 and would just complicate decoding and waste opcode space.

With only a maximum of 64 opcodes, explicit compare, and no mention of any delay slots or coprocessors, I don't think a dedicated NOP would be necessary for this particular CPU. Even if there was an FPU with exposed pipeline, you could special-case OR R0, R0 for the no cycle NOP and use OR with any other registers for the one-cycle NOP, so there's still no need to waste opcodes for a dedicated NOP.