OSDev.org

Good afternoon OSdevers (well at least it's afternoon here :p),

Last Friday I started playing in Logisim (Quite a nice program IMHO) and I wanted a challenge So I decided to draw a complete CPU and complete with my own opcodes
I'm now finished with a big part of it and logisim feel like it doesn't like it (I uses +300MB RAM and a lot of CPU time):p There are big number of flaws and probably some bugs in it. It is also vastly inefficient ATM. However it is working and I will improve the design.
If you start the simulation you will need to press the reset button ones. Then the CPU will execute some code from the bios (the code outputs H to the little screen and jumps to 0xa in the RAM to start executing code there).

Please comment on my opcodes (Bugs, weird behavior, opcode requests, ...) because I want to vastly improve them. I have some ideas but since I don't know much about asm I thought it would be good to ask the opinion of some experts
I will also improve all the circuits in the current processor to make it more efficient.

You might want to check out the Zpu (http://opencores.org/project,zpu). It is free, and includes a complete tool chain with gcc and g++. It is very minimal, and I believe it would be easy to modify for new and interesting purposes.

Perhaps the most interesting thing about it is it uses 1 byte opcodes.

Thanks for that :p My next design is taking shape in my head. I got some ideas already

Several basic things:
opcodes are ambiguous. There are for instance several opcodes that start with 12 bits of zero.
Not all opcodes are multiples of 8 bits, or even 4 bits.
There's a lot of wastage in opcode space. The opcodes seem to be designed for 32-bits each, but 20 bits are wasted in many cases.
You can fix the above by building an opcode map.

As for the formatting (tabs that aren't 4 or 8 ), some ideas (this is a real cpu): http://www.dimensionalrift.homelinux.ne ... te-bi.html

janPieterv wrote:Thanks for that :p My next design is taking shape in my head. I got some ideas already

You may also want to look at how several existing processors do things. ARM has quite a few nice tricks to get decent code density out of a fixed 32-bit instruction length. Two examples: condition codes on *everything* and the "push multiple" instruction, which allows any combination of registers (not single/all like on x86) to be pushed/popped in a single instruction.

OK I have read a bit about the ARM instruction set (here) and now I will try to pay attention when creating my opcodes because the previous ones I had written in about an hour :p
Thanks for all the help. I'll be back with my new opcodes soon :p

Ok I'm back with a first small part of my new Opcodes. And this time I have taken some time to put them together. I have more operation coming but these are done already so I thought to just post them already and see what everyone thinks.

Why do your opcode fields move around all the time? Most architectures keep them in the same place. Makes the logic much simpler.

To fit in more data. I thought it was a good idea
For example in the Add instruction you can do register + Value OR register + (value << x) OR register + (register << x).
If I did everything as: Condition 0 0000 F 11 cccc aaaa K bbbb 00 sssss
Then I could switch between a register and a value using one of the two zeroes but in that case the value can only be 4/5bit and a 5bit shift. But I did it differently to allow a 13 bit value.
I'm not sure if this is a good choice or not but I thought it was good for code density.

Here is a simple rearrangement that might work better: Try to keep register specifies aligned - no matter what. Split up immediates if you need to. Opcode bits can go anywhere pretty freely.