Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Thomas Koenig <tkoenig@netcologne.de>
Newsgroups: comp.arch
Subject: Re: "Mini" tags to reduce the number of op codes
Date: Mon, 8 Apr 2024 06:21:43 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 78
Message-ID: <uv02dn$3b6ik$1@dont-email.me>
References: <uuk100$inj$1@dont-email.me>
 <6mqu0j1jf5uabmm6r2cb2tqn6ng90mruvd@4ax.com>
 <15d1f26c4545f1dbae450b28e96e79bd@www.novabbs.org>
 <lf441jt9i2lv7olvnm9t7bml2ib19eh552@4ax.com> <uuv1ir$30htt$1@dont-email.me>
 <d71c59a1e0342d0d01f8ce7c0f449f9b@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 08 Apr 2024 06:21:43 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d6deb714ccc72ec1e80045745fb7bd3c";
	logging-data="3512916"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+2XGIqqUzjk8K8QMlGuMyfqps8HSdazN8="
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:J4ZoztDGY+j7kyoZlsxCyeQmbHg=
Bytes: 4533

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.