No Subject

[jfox@xxxxxxxxxx (Jeff Fox)]

Dear MISC readers,

>> You are right about P32 where there will be a one bit RET instruction.
>> I don't know if that means that Chuck will replace the normal RET 
>> instruction with something else.
>
>There are unassigned instruction codes in MuP21 and F21. Maybe there will 
>be one more in P32 :-)
>
>--
>Penio Penev <Penev@venezia.Rockefeller.edu> 1-212-327-7423

I hope it is ok to jump in and answer so many questions.  At times
it may seem like I am cutting people off how are offering new ideas.

It is just that I have often discussed some things with Chuck several
times, and know what he would say.  It is interesting, and I think it
is much easier to answer these questions here so everyone can understand
more.  I try to refer people to the archives for some answers to their
questions rather than explain things too many times.

It seems that instruction decode is one of the most constraining things
in Chuck's design.  It makes sense when you think about the timing and
the fact that certain properties of all 4 instructions such at whether
they are memory access type, and which is the last of any memory
access type instructions must be done as fast as possible.  This is one
of the primitive steps that makes up instruction execution.  So given
this it is one of the critical circuits to performance.

Given that Chuck is not able to decode all 32 opcodes.  He can make
some of the opcodes he can decode do different things in different
slots.  He does this with F21 branch instructions, and with the
video processor instructions on MuP21.  

He seems pretty much limited to the number of opcodes that you see on
F21, and there are some restrictions to which  types of instruction
can be placed into which opcode.  This makes sense considering the way
instruction decode and memory_instruction_scan works before instruction
prefetch.

Usually to get a new instruction you have to give up one of the F21
instructions, or make it work a different way in a certain slot.  All
this adds complexity, or at least work.

I had requested that OVER become SWAP.  I think I would still prefer
this.  Chuck likes OVER more.  SWAP has a higher frequency and you can
do OVER in a macro with SWAP more easily than you do SWAP in a macro
with OVER.  (if you use A both are the same same speed, 4 instructions,
but you need A for a 4 instruction SWAP)

I have little if any use for +*, it is too restricting.  You will note
that 2/ is not the same as 2/ on MuP21.

+* is not used anywhere in P21Forth, not even in fractional math, cordic,
etc.  If I were to convince Chuck to provide a new instruction I could
get a non-memory access instruction to replace the +* opcode.

I have asked a few people and no one except Chuck seems to be useing
+*.  It can be used for a fast 8x8 multiply on a 20 bit chip, but not
really a 10x10, 9x9 is possible.  Other general purpose multiplies are
faster than this type of multiply on some data, and slower on others.

Anyway MISC is a forum where if people suggest ideas for changes to
Chuck's MISC instruction set, I can in some cases tell you what he
would say.  For a long time I tried experimenting with new or different
instructions on the simulated machines.

One I would like to look into deeper is the idea of an opcode for use
in a bit threaded interpreter.  I have looked at an opcode for DTC
and it was nice.  

Any other ideas out there about MISC instruction sets?  It is an interesting
topic because it is after all Minimal_Instruction_Set_Computers!

To a great extent I think that the MISC instruction set is Chuck's current
vision of Forth.  You would not expect him to be using ANS.  ;-)

Jeff