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

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

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.

This is why, if you want to copy Mill, you have to do it properly:
Mill does NOT care about the type of data loaded into a particular belt slot, only the size and if it is a scalar or a vector filling up the full belt slot. In either case you will also have marker bits for special types like None and NaR.
So scalar 8/16/32/64/128 and vector 8x16/16x8/32x4/64x2/128x1 (with the last being the same as the scalar anyway).
Only load ops and explicit widening/narrowing ops sets the size tag bits, from that point any op where it makes sense will do the right thing for either a scalar or a short vector, so you can add 16+16 8-bit vars with the same ADD encoding as you would use for a single 64-bit ADD.
We do NOT make any attempt to interpret the actual bit patterns sotred within each belt slot, that is up to the instructions. This means that there is no difference between loading a float or an int32_t, it also means that it is perfectly legel (and supported) to use bit operations on a FP variable. This can be very useful, not just to fake exact arithmetic by splitting a double into two 26-bit mantissa parts:
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"