With the help of some excellent feedback from @roelh I am reworking the instruction set. I have decided to move away from the load / store syntax and am moving to a 68K style move instruction to help avoid duplicating instructions. Each two operand instruction will be in the form of INSTR source,destination. I am building a database in Access to help me come up with my list of instruction. I've created a table of Operations :
And a table of Operands:
A B X Y AB XY SP PC # ## . $ $## SR +SP -SP +XY +AB
(symbols are placeholders for Immediate, Absolute, Indirect and Immediate Indirect.)
The tables have info like the width of each operand, the number of operands for the operations. and notes. Just combining all these without using the same operand twice results in almost 8,000 instructions. I am working on using query's to help me build groups of instructions. This will help me prioritize modes for different registers. I want to give high functionality to the stack. I will be using AB as the data focused register and XY as the pointer focused one. I want to have the rules for the instructions be logical so you can easily remember which registers are capable of what. My first version of instructions had limitations on pointer style programming. With only 2 pointer registers (besides SP and PC) being able to do operations on memory will be important I think.
I will look at coming up with an easy way of auto publishing my Instruction info from the database somehow. I know office 365 have features similar to Google docs so It should be possible. Just haven't played around with it yet.
I'm already thinking that If this goes well (I build it in a reasonable amount of time). I might try taking a crack at a 16 bit CPU. I love the idea of having enough bits in the instruction code to have 3 bits for source register 3 bits for destination, 4 or 5 bits for operation etc. would be really cool. But I am getting way ahead of myself. Lets just get this one done. (reminding myself to watch the feature creep).