Warning: mysqli::__construct(): (HY000/1203): User howardkn already has more than 'max_user_connections' active connections in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\includes\artfuncs.php on line 21
Failed to connect to MySQL: (1203) User howardkn already has more than 'max_user_connections' active connectionsPath: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Stephen Fuld
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:
References:
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:
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)