Path: ...!weretis.net!feeder6.news.weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB-Alt <bohannonindustriesllc@gmail.com>
Newsgroups: comp.arch
Subject: Re: "Mini" tags to reduce the number of op codes
Date: Tue, 16 Apr 2024 17:46:00 -0500
Organization: A noiseless patient Spider
Lines: 76
Message-ID: <uvmv38$16acb$1@dont-email.me>
References: <uuk100$inj$1@dont-email.me> <uukckh$4g83$1@dont-email.me>
 <uvmstq$ql2d$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 17 Apr 2024 00:46:18 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="f91ef60a688902118f0b09a24a35e407";
	logging-data="1255819"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18GK6UQKun2J8q6BW9ACaLopVsn1gVJ7Y0="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:W6XHd2xEMeD/LJvXDbkCNCLTss0=
Content-Language: en-US
In-Reply-To: <uvmstq$ql2d$2@dont-email.me>
Bytes: 3540

On 4/16/2024 5:08 PM, Stephen Fuld wrote:
> On 4/3/2024 1:02 PM, Thomas Koenig wrote:
>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> schrieb:
>>
>> [saving opcodes]
>>
>>
>>> The idea is to add 32 bits to the processor state, one per register
>>> (though probably not physically part of the register file) as a tag.  If
>>> set, the bit indicates that the corresponding register contains a
>>> floating-point value.  Clear indicates not floating point (integer,
>>> address, etc.).
>>
>> I don't think this would save a lot of opcode space, which
>> is the important thing.
>>
>> A typical RISC design has a six-bit major opcode.
>> Having three registers takes away fifteen bits, leaving
>> eleven, which is far more than anybody would ever want as
>> minor opdoce for arithmetic instructions.  Compare with
>> https://en.wikipedia.org/wiki/DEC_Alpha#Instruction_formats
>> where DEC actually left out three bits because they did not
>> need them.
> 
> I think that is probably true for 32 bit instructions, but what about 16 
> bit?
> 

At least, as I see it...


If 4 bit registers:
   16-4-4 => 8
If 5 bit registers:
   15-5-5 => 6

Realistically, I don't think 6 bits of opcode is enough except if the 
purpose of the 16-bit ops is merely to shorten some common 32-bit ops.

But, a subset of instructions can use 5-bit fields (say, MOV, EXTS.L, 
and common Load/Store ops).

Say (in my notation):
   MOV    Rm, Rn
   EXTS.L Rm, Rn
   MOV.L  (SP, Disp), Rn
   MOV.Q  (SP, Disp), Rn
   MOV.X  (SP, Disp), Xn
   MOV.L  Rn, (SP, Disp)
   MOV.Q  Rn, (SP, Disp)
   MOV.X  Xn, (SP, Disp)
As, these tend to be some of the most commonly used instructions.

For most everything else, one can limit things either to the first 16 
registers, or the most commonly used 16 registers (if not equivalent to 
the first 16).

Though, for 1R ops, it can make sense to have 5-bit registers.


I don't really think 3-bit register fields are worth bothering with; 
even if limited to the most common registers. Granted, being limited to 
2R encodings is also limiting.

Granted, both Thumb and RVC apparently thought 3-bit register fields 
were worthwhile, so...

Similarly, not worth bothering (at all) with 6-bit register fields in 
16-bit ops.


Though, if one has 16-bit VLE, a question is how is best to split up 16 
vs 32-bit encoding space.

....