Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Stephen Fuld <sfuld@alumni.cmu.edu.invalid>
Newsgroups: comp.arch
Subject: Re: "Mini" tags to reduce the number of op codes
Date: Tue, 16 Apr 2024 15:06:48 -0700
Organization: A noiseless patient Spider
Lines: 67
Message-ID: <uvmspo$ql2c$1@dont-email.me>
References: <uuk100$inj$1@dont-email.me> <YshPN.227779$hN14.133879@fx17.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 17 Apr 2024 00:06:51 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="e4560d6e9e80920818ac28626eb60e90";
	logging-data="873548"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/ze8BLQS5Z2lyR4hGsbx4q111jtj1XrIs="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:5fpoTIeGdNc4O2/OfRrk4qeYJeI=
Content-Language: en-US
In-Reply-To: <YshPN.227779$hN14.133879@fx17.iad>
Bytes: 4049

On 4/3/2024 11:44 AM, EricP wrote:
> Stephen Fuld wrote:
>> There has been discussion here about the benefits of reducing the 
>> number of op codes.  One reason not mentioned before is if you have 
>> fixed length instructions, you may want to leave as many codes as 
>> possible available for future use.  Of course, if you are doing a 
>> 16-bit instruction design, where instruction bits are especially 
>> tight, you may save enough op-codes to save a bit, perhaps allowing a 
>> larger register specifier field, or to allow more instructions in the 
>> smaller subset.
>>
>> It is in this spirit that I had an idea, partially inspired by Mill’s 
>> use of tags in registers, but not memory.  I worked through this idea 
>> using the My 6600 as an example “substrate” for two reasons.  First, 
>> it has several features that are “friendly” to the idea.  Second, I 
>> know Mitch cares about keeping the number of op codes low.
>>
>> Please bear in mind that this is just the germ of an idea.  It is 
>> certainly not fully worked out.  I present it here to stimulate 
>> discussions, and because it has been fun to think about.
>>
>> 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.).  There would be two additional instructions, load 
>> single floating and load double floating, which work the same as the 
>> other 32- and 64-bit loads, but in addition to loading the value, set 
>> the tag bit for the destination register.  Non-floating-point loads 
>> would clear the tag bit.  As I show below, I don’t think you need any 
>> special "store tag" instructions.
> 
> If you are adding a float/int data type flag you might as well
> also add operand size for floats at least, though some ISA's
> have both int32 and int64 ALU operations for result compatibility.

Not needed for My 66000, as all floating point loads convert the loaded 
value to double precision.

big snip

> Currently the opcode data type can tell the uArch how to route
> the  operands internally without knowing the data values.
> For example, FPU reservation stations monitor float operands
> and schedule for just the FPU FADD or FMUL units.
> 
> Dynamic data typing would change that to be data dependent routing.
> It means, for example, you can't begin to schedule a uOp
> until you know all its operand types and opcode.

Seems right.


> 
> Looks like it makes such distributed decisions impossible.
> Probably everything winds up in a big pile of logic in the center,
> which might be problematic for those things whose complexity grows N^2.
> Not sure how significant that is.

Could be.  Again, IANAHG.



-- 
  - Stephen Fuld
(e-mail address disguised to prevent spam)