By whygee on Monday 19 March 2012, 05:09

I started writing the microYASEP for a specific project, one month ago, and started to write more software.

The benefits of writing code while designing the architecture can't be over emphasised. When you eat your own food, you are more careful of the recipes and the ingredients !

I had thought about how to use the last remaining condition code, I thought about an "overflow" bit but it's useless because the comparisons are already containing the signed/unsigned information. Writing code made me realise that the ZERO condition was not enough as many operations require a scratch register for the result of a comparison (using CMPU). So I made a "EQ" ( equal) flag and I reduced the register pressure a bit.

About the title : my first real program is a bit more than 200 bytes so it is time to evaluate my early estimations. In 2009 I guessed that in average one half of the instructions are "long" (4 bytes) (and the other half are short, 2 bytes) and now I have a first result :

The program comprises 70 instructions, 34 are short and 36 are long. Pretty good guess so one can consider the YASEP architecture as a "roughly 24-bit instruction machine" :-)

Furthermore, I know that I had a loooooot of time to get used to the architecture and learn how to use it efficiently, but overall the YASEP is pretty comfortable to use. I could do almost everything with just 8 opcodes :

ADD MOV GET PUT CALL AND XOR CMPU

The only limitation I found was the very short (-8 to +7) 4 bits immediate range. Sometimes it would be very handy to extend it to 5 or 6 bits, for short jumps or loops for example, but it was a conscious compromise from the start, as finding more bits somewhere would make the architecture more complex and less orthogonal... Food for thought for the next architecture (wink...)

20200410:

The YASEP is designed for code compactness rather than raw speed so the increase in complexity is a good compromise for the smaller program size.

The short range of jumps is still a big problem, that was addressed later in 2 ways :

• PC points to 16-bits words, not bytes
• short immediates 0 to 7 trigger the carry input if the opcode is ADD, to expand the addressing range a bit. And ADD 0 makes no practical sense...
• Later, with YASEP2014, the long form iRR extended the immediate field to 6 bits, reducing the update field size down to 2 bits.