Re: "Mini" tags to reduce the number of op codes

MitchAlsup1 <mitchalsup@aol.com> schrieb:

Thomas Koenig wrote:
>

John Savard <quadibloc@servername.invalid> schrieb:

>

Thus, instead of having mode bits, one _could_ do the following:
>
Usually, have 28 bit instructions that are shorter because there's
only one opcode for each floating and integer operation. The first
four bits in a block give the lengths of data to be used.
>
But have one value for the first four bits in a block that indicates
36-bit instructions instead, which do include type information, so
that very occasional instructions for rarely-used types can be mixed
in which don't fill a whole block.
>
While that's a theoretical possibility, I don't view it as being
worthwhile in practice.

>

I played around a bit with another scheme:  Encoding things into
128-bit blocks, with either 21-bit or 42-bit or longer instructions
(or a block header with six bits, and 20 or 40 bits for each
instruction).

>
Not having seen said encoding scheme:: I suspect you used the Rd=Rs1
destructive operand model for the 21-bit encodings. Yes :: no ??

It was not very well developed, I gave it up when I saw there wasn't
much to gain.

Otherwise one has 3×5-bit registers = 15-bits leaving only 6-bits
for 64 OpCodes.

There could have been a case for adding this (maybe just for
the a few frequent ones: "add r1,r2,r3",  "add r1,r2,-r3", "add
r1,r2,#num" and "add r1,r2,#-num", but I did not pursue that
further.

I looked at load and store instructions with short offsets
(these would then have been scaled), and short branches.  But
the 21-bit opcode space filled up really, really rapidly.

Also, it is easy to synthesize a 3-register operation from
a 2-register operation and a memory move.  If the decoder is
set up for 42 bits anyway, instruction fusion also a possibility.
This got a bit weird.

Now if you have floats and doubles and signed and
unsigned, you get 16 of each and we have not looked at memory
references or branching.

For somebody who does Fortran, I find the frequency of floating
point instructions surprisingly low, even in Fortran code.

>

Did that look promising?  Not really; the 21 bits offered a lot
of useful opcode space for two-register operations and even for
a few of the often-used three-register, but 42 bits was really
a bit too long, so the advantage wasn't great.  And embedding
32-bit or 64-bit instructions in the code stream does not really
fit the 21-bit raster well, so compared to an ISA which can do so
(like My 66000) it came out at a disadvantage.  Might be possible
to beat RISC-V, though.

>
But beating RISC-V is easy, try getting you instruction count down
to VAX counts without losing the ability to pipeline and parallel
instruction execution.

At handwaving accuracy::
VAX      has 1.0 instructions
My 66000 has 1.1 instructions
RISC-V   has 1.5 instructions

To reach VAX instruction density, one would have to have things
like memory operands (with the associated danger that compilers
will not put intermediate results in registers, but since they have
been optimized for x86 for decades, they are probably better now)
and load with update, which would then have to be cracked
into two micro-ops.  Not sure about the benefit.