Re: "Mini" tags to reduce the number of op codes

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)