Path: ...!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: "Mini" tags to reduce the number of op codes
Date: Wed, 3 Apr 2024 09:43:44 -0700
Organization: A noiseless patient Spider
Lines: 93
Message-ID: <uuk100$inj$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 03 Apr 2024 16:43:44 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="76b2f13c17873d1fc6bc86107ab60e09";
	logging-data="19187"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/UECkw+Y831HOaeBB5sUYMWBYnLPcayHo="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:bjcK9+8ysRcmKO8Yt6s+y20x/wI=
Content-Language: en-US
Bytes: 5970

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.

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
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.

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 
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.

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?  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?  If it causes an 
extra cycle per instruction, then it is almost certainly not worth it. 
IANAHG, so I don’t know.  But even if it doesn’t cost any performance, I 
think the overall gains are pretty small, and probably not worth it 
unless the op-code space is really tight (which, for My 66000 it isn’t).

Anyway, it has been fun thinking about this, so I hope you don’t mind 
the, probably too long, post.
Any comments are welcome.


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