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

BGB-Alt wrote:

 FWIW:
This doesn't seem too far off from what would be involved with dynamic typing at the ISA level, but with many of same sorts of drawbacks...

Say, for example, top 2 bits of a register:
   00: Object Reference
     Next 2 bits:
       00: Pointer (with type-tag)
       01: ?
       1z: Bounded Array
   01: Fixnum (route to ALU)
   10: Flonum (route to FPU)
   11: Other types
     00: Smaller value types
       Say: int/uint, short/ushort, ...
     ...

So, you either have 66-bit registers, or you have 62-bit FP numbers ?!?
This solves nobody's problems; not even LISP.

One issue:
Decoding based on register tags would mean needing to know the register tag bits at the same time the instruction is being decoded. In this case, one is likely to need two clock-cycles to fully decode the opcode.

Not good. But what if you don't know the tag until the register is delivered from a latent FU, do you stall DECODE, or do you launch and make the instruction
queue element have to deal with all outcomes.

ID1: Unpack instruction to figure out register fields, etc.
ID2: Fetch registers, specialize variable instructions based on tag bits.

For timing though, one ideally doesn't want to do anything with the register values until the EX stages (since ID2 might already be tied up with the comparably expensive register-forwarding logic), but asking for 3 cycles for decode is a bit much.

Otherwise, if one does not know which FU should handle the operation until EX1, this has its own issues.

Real-friggen-ely

                                    Or, possible, the FU's decide whether to accept the operation:
   ALU: Accepts operation if both are fixnum, FPU if both are Flonum.

What if IMUL is performed in FMAC, IDIV in FDIV,... Int<->FP routing is
based on calculation capability {Even CDC 6600 performed int × in the FP × unit (not in Thornton's book, but via conversation with 6600 logic
designer at Asilomar some time ago. All they had to do to get FP × to
perform int × was disable 1 gate.......)

But, a proper dynamic language allows mixing fixnum and flonum with the result being implicitly converted to flonum, but from the FPU's POV, this would effectively require two chained FADD operations (one for the Fixnum to Flonum conversion, one for the FADD itself).

That is a LANGUAGE problem not an ISA problem. SNOBOL allowed one to add
a string to an integer and the string would be converted to int before.....

Many other cases could get hairy, but to have any real benefit, the CPU would need to be able to deal with them. In cases where the compiler deals with everything, the type-tags become mostly moot (or potentially detrimental).

You are arguing that the added complexity would somehow pay for itself.
I can't see it paying for itself.

But, then, there is another issue:
   C code expects C type semantics to be respected, say:
     Signed int overflow wraps at 32 bits (sign extending);

maybe

     Unsigned int overflow wraps at 32 bits (zero extending);

maybe

     Variables may not hold values out-of-range for that type;

LLVM does this GCC does not.

     The 'long long' and 'unsigned long long' types are exactly 64-bit;

At least 64-bit not exactly.

       ...
     ...

If one has tagged 64-bit registers, then fixnum might not hold the entire range of 'long long'. If one has 66 or 68 bit registers, then memory storage is a problem.

Ya think ?

If one has untagged registers for cases where they are needed, one has not saved any encoding space.

I give up--not worth trying to teach cosmologist why the color of the lipstick going on the pig is not the problem.....