ISA design

[amd64pager]

Hello,
For designing my new ISA for my planned CPU(Hack32),I would like suggestions on what instructions are most commonly used and would save memory and increase performance.(This will be a pipelined architecture and is 32 bits)
Here are the current instructions planned:
-A move constant instruction,which will move constants into a register
-A compute instruction which will compute operations on registers(NOT CONSTANTS)
-A move to memory instruction which will move data from registers to memory
-A retrieve from memory instruction which will move data from memory to registers
-A jump instruction which will do a conditional jump depending on the ALU flags or a unconditional jump
(Note:All computations will complete in 2 cycles - even multiplication)
It has the following units:
Fetch - fetches an instruction from memory
Decode - decodes an instruction
Reg - Reads memory and stores in register,only has purpose for retrieve instruction and is skipped for other instructions
Compute - Computes,only has purpose for compute instruction and is skipped for other instructions
Mem - Reads register and stores in memory,only has purpose for store instruction and is skipped for other instructions

And please don't ask for a MMU and other stuff,I will implement those in the next version.

[Combuster]

There's little description beyond "it's a 32-bit load-store (RISC) architecture". What makes it similar or different compared to say... PowerPC? SuperH?

There's no background on architectural goals and implementation strategies to make meaningful suggestions beyond "here is MY idea. It pwns". There's some work you need to do if you want a non-generic response.

[ACcurrent]

SIMDs never hurt speed. however I do not know wether your aim is to target low power or high power devices.

[Rudster816]

Implement DCPU-16?

Thats a funny joke. I got about 20% into a Verilog implementation of DCPU-16 to learn Verilog, but quit after realizing how stupid the ISA was. What pushed me over the edge was realizing that you could do memory to memory operations.

SIMDs never hurt speed. however I do not know wether your aim is to target low power or high power devices.

Anything that takes up space on the die potentially hurts speed. The extra space taken up by SIMD logic\register files could be used to implement additional scalar execution units, larger caches, etc. In the case of SIMD instructions, they don't necessarily have to actually be executed in parallel, which can cause programs that assume they are to run poorer with SIMD than SISD. Just because the ISA defines an instruction that can operate on 4 packed doubles, doesn't mean that it has 4 64 bit FP multipliers to use at any given time.


@OP

You're confusing microarchitecture with parts if the ISA. A proper design would never define how long an instruction would take, nor would it define certain execution units. An ISA defines an interface to the CPU that is visible to the programmer that is the same across all implementations. An ISA is just another abstraction much like a software libraries API is.

If you just want to design a very simple 32 bit architecture to implement in an HDL, its not very difficult to do. People often make the assumption that just because an architecture works on 32 bit words, its some complex monstrosity.

http://en.wikipedia.org/wiki/PIC_microcontroller

The PIC ISA is pretty basic, yet can accomplish practically everything that x86 can. You really only need a basic set of load\store and arithmetic operations.

At any rate, you need to have a fairly detailed knowledge of exactly how CPU's work in order to design an ISA that makes sense for a modern microprocessor\microcontroller. You also need to understand software at the assembly\machine code level. If you're designing an ISA for a general purpose CPU, you need to understand what kinds of instructions that a compiler will benefit from, and ones that will probably never be used by one. IMO, one of the greatest oversights of casual ISA discussion\design is looking at the instructions from a programmers perspective, and not a compilers. After all, an overwhelming majority of code for general purpose CPU's (e.g. not purely embedded) is written in a programming language that isn't assembly.