Path: ...!news.misty.com!weretis.net!feeder6.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: "Mini" tags to reduce the number of op codes
Date: Sun, 7 Apr 2024 20:41:45 +0000
Organization: Rocksolid Light
Message-ID: <9280b28665576d098af53a9416604e36@www.novabbs.org>
References: <uuk100$inj$1@dont-email.me> <6mqu0j1jf5uabmm6r2cb2tqn6ng90mruvd@4ax.com> <15d1f26c4545f1dbae450b28e96e79bd@www.novabbs.org> <lf441jt9i2lv7olvnm9t7bml2ib19eh552@4ax.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="431128"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="PGd4t4cXnWwgUWG9VtTiCsm47oOWbHLcTr4rYoM0Edo";
User-Agent: Rocksolid Light
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Site: $2y$10$VtVxYWfxsGsp3TNJYojBEuSD7j7WWK.HxFwo9YEnxGBt3OOy8zuzq
Bytes: 3382
Lines: 61

John Savard wrote:

> On Fri, 5 Apr 2024 21:34:16 +0000, mitchalsup@aol.com (MitchAlsup1)
> wrote:

>>Early in My 66000 LLVM development Brian looked at the cost of having 
>>only 1 FP OpCode set--and it did not look good--so we went back to the
>>standard way of an OpCode for each FP size × calculation.

> I do tend to agree.

> However, a silly idea has now occurred to me.

> 256 bits can contain eight instructions that are 32 bits long.

> Or they can also contain seven instructions that are 36 bits long,
> with four bits left over.

> So they could contain *nine* instructions that are 28 bits long, also
> with four bits left over.

I agree with the arithmetic going into this statement. What I don't 
have sufficient data concerning is "whether these extra formats pay
for themselves". For example, how many of the 36-bit encodings are
irredundant with the 32-bit ones, and so on with the 28-bit ones.

Take::

     ADD    R7,R7,#1

I suspect there is a 28-bit form, a 32-bit form, and a 36-bit form
for this semantic step, that you pay for multiple times in decoding
and possibly pipelining. {{There may also be other encodings for
this; such as:: INC R7}}

> 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.

How do you attach 32-bit or 64-bit constants to 28-bit instructions ??

How do you switch from 64-bit to Byte to 32-bit to 16-bit in one
set of 256-bit instruction decodes ??

> 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.

In complicated if-then-else codes (and switches) I often see one inst-
ruction followed by a branch to a common point. Does your encoding deal 
with these efficiently ?? That is:: what happens when you jump to the
middle of a block of 36-bit instructions ??

> While that's a theoretical possibility, I don't view it as being
> worthwhile in practice.

Agreed.............

> John Savard