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 16:44:27 -0700
Organization: A noiseless patient Spider
Lines: 152
Message-ID: <uvn2gr$ql2d$3@dont-email.me>
References: <uuk100$inj$1@dont-email.me> <uukduu$4o4p$1@dont-email.me>
 <420556afacf3ef3eea07b95498bcbef0@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 17 Apr 2024 01:44:28 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="e4560d6e9e80920818ac28626eb60e90";
	logging-data="873549"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19PxXJH7XWpNloOwihnkImyuH+K1NSlnRw="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:wv6JX54YZLfoBVQ0pmWQ+PRoubw=
Content-Language: en-US
In-Reply-To: <420556afacf3ef3eea07b95498bcbef0@www.novabbs.org>
Bytes: 7558

On 4/3/2024 2:30 PM, MitchAlsup1 wrote:
> BGB-Alt wrote:
> 
>> On 4/3/2024 11:43 AM, 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 
>                 66000
Sorry.  Typo.



>>> 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.
> 
> What do you do when you want a FP bit pattern interpreted as an integer, 
> or vice versa.

As I said below, if you need that, you can use an otherwise :"useless" 
instruction, such as ORing a register with itself the modify the tag bits.




> 
>>> When executing arithmetic instructions, if the tag bits of both 
>>> sources of an instruction are the same, do the appropriate operation 
>>> (floating or integer), and set the tag bit of the result register 
>>> appropriately.
>>> If the tag bits of the two sources are different, I see several 
>>> possibilities.
>>>
>>> 1.    Generate an exception.
>>> 2.    Use the sense of source 1 for the arithmetic operation, but 
>>> perform the appropriate conversion on the second operand first, 
>>> potentially saving an instruction
> 
> Conversions to/from FP often require a rounding mode. How do you specify 
> that?

Good point.



> 
>>> 3.    Always do the operation in floating point and convert the 
>>> integer operand prior to the operation.  (Or, if you prefer, change 
>>> floating point to integer in the above description.)
>>> 4.    Same as 2 or 3 above, but don’t do the conversions.
>>>
>>> I suspect this is the least useful choice.  I am not sure which is 
>>> the best option.
>>>
>>> Given that, use the same op code for the floating-point and fixed 
>>> versions of the same operations.  So we can save eight op codes, the 
>>> four arithmetic operations, max, min, abs and compare.  So far, a net 
>>> savings of six opcodes.
>>>
>>> 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.
> 
> Hands waving:: "Danger Will Robinson, Danger" more waving of hands.

Agreed.


>>> I think this all works fine for a single compilation unit, as the 
>>> compiler certainly knows the type of the data.  But what happens with 
>>> separate compilations?  The called function probably doesn’t know the 
> 
> The compiler will certainly have a function prototype. In any event, if FP
> and Integers share a register file the lack of prototype is much less 
> stress-
> full to the compiler/linking system.
> 
>>> tag value for callee saved registers.  Fortunately, the My 66000 
>>> architecture comes to the rescue here.  You would modify the Enter 
>>> and Exit instructions to save/restore the tag bits of the registers 
>>> they are saving or restoring in the same data structure it uses for 
>>> the registers (yes, it adds 32 bits to that structure – minimal 
>>> cost).  The same mechanism works for interrupts that take control 
>>> away from a running process.
> 
> Yes, but we do just fine without the tag and without the stuff mentioned 
> above. Neither ENTER nor EXIT care about the 64-bit pattern in the 
> register.

I think you need it for callee saved registers to insure the tag is set 
correctly for the calling program upon return to it.


> 
>>> I don’t think you need to set or clear the tag bits without doing 
>>> anything else, but if you do, I think you could “repurpose” some 
>>> other instructions to do this, without requiring another op-code.   
>>> For example, Oring a register with itself could be used to set the 
>>> tag bit and Oring a register with zero could clear it.  These should 
>>> be pretty rare.
> 
>>> 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?
> 
> No.
> 
>>            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?
> 
> The problem is you have put decode dependent on dynamic pipeline 
> information.
> I suggest you don't want to do that. Consider a change from int to FP 
> instruction
> as a predicated instruction, so the pipeline cannot DECODE the 
> instruction at
> hand until the predicate resolves. Yech.

Good point.



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