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: 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:02:13 -0700
Organization: A noiseless patient Spider
Lines: 73
Message-ID: <uvmsh6$ql2d$1@dont-email.me>
References: <uuk100$inj$1@dont-email.me>
 <2024Apr3.192405@mips.complang.tuwien.ac.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 17 Apr 2024 00:02:15 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="e4560d6e9e80920818ac28626eb60e90";
	logging-data="873549"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19bOa7EVK+T9BfGsZCFYpzKeu/4URyDSfI="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:zpu5qRhcr+Faj4O/oGoDAT3y41U=
Content-Language: en-US
In-Reply-To: <2024Apr3.192405@mips.complang.tuwien.ac.at>
Bytes: 4182

On 4/3/2024 10:24 AM, Anton Ertl wrote:
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>> 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.
> ...
>> But we can go further.  There are some opcodes that only make sense for
>> FP operands, e.g. the transcendental instructions.  And there are some
>> operations that probably only make sense for non-FP operands, e.g. POP,
>> FF1, probably shifts.  Given the tag bit, these could share the same
>> op-code.  There may be several more of these.
> 
> Certainly makes reading disassembler output fun (or writing the
> disassembler). 

Good point.  It probably isn't too bad for the arithmetic operations, 
etc, but once you extend it as I suggested in the last paragraph it gets 
ugly.  :-(


big snip
> 
>> That is as far as I got.  I think you could net save perhaps 8-12 op
>> codes, which is about 10% of the existing op codes - not bad.  Is it
>> worth it?  To me, a major question is the effect on performance.  What
>> is the cost of having to decode the source registers and reading their
>> respective tag bits before knowing which FU to use?
> 
> In in OoO CPU, that's pretty heavy.

OK, but in the vast majority of cases (i.e. unless there is something 
like a conditional branch that uses floating point  or integer depending 
upon whether the branch is taken.) the flag bit that a register will 
have can be known well in advance.  As I said, IANAHG, but that might 
make it easier.



> But actually, your idea does not need any computation results for
> determining the tag bits of registers (except during EXIT),

But even here, you almost certainly know what the tag bit for any given 
register is long before you execute the EXIT instruction.  And remember, 
on MY 66000 EXIT is performed lazily, so you have time and the mechanism 
is in place to wait if needed.


> so you
> probably can handle the tags in the front end (decoder and renamer).
> Then the tags are really separate and not part of the rgisters that
> have to be renamed, and you don't need to perform any waiting on
> ENTER.
> 
> However, in EXIT the front end would have to wait for the result of
> the load/store unit loading the 32 bits, unless you add a special
> mechanism for that.  So EXIT would become expensive, one way or the
> other.

Yes.



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