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

On 4/3/2024 4:53 PM, MitchAlsup1 wrote:

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.
 

Yeah, there is likely no way to make this worthwhile...

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.
 

It is likely that the pipeline would need to stall until results are available.
It is also likely that such a CPU would have a minimum effective latency of 2 or 3 clock cycles for *every* instruction (and probably 4 or 5 cycles for memory load), in addition to requiring pipeline stalls.

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
 

These issues could be a deal-breaker for such a CPU.

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

Then you have a mess...
So, probably need to sort it out before EX in any case.

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

If you have dynamic types in hardware in this way, then effectively the typesystem mechanics switch from being a language issue to a hardware issue.
One may also end up with, say, a CPU that can run Scheme or JavaScript or similar, but likely couldn't run C without significant hassles.

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.
 

One either goes all in, or abandons the idea entirely.
There isn't really a middle option in this scenario (then one just ends up with something that is bad at everything).
I was not saying it could work, but in a way, pointing out the issues that would likely make this unworkable.
Though, that said, there could be possible merit in a CPU core that could run a language like ECMAScript at roughly C like speeds, even if it was basically unusable for pretty much anything else.
Though, for ECMAScript, also make a case for taking the SpiderMonkey option and largely abandoning the use of an integer ALU (instead running all of the integer math through the FPU; which could be modified to support bitwise integer operations and similar as well).

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

I am dealing with some code that has a bad habit of breaking if integer overflows don't happen in the expected ways (say, the ROTT engine is pretty bad about this one...).
When I first started working on my ROTT port, there was also a lot of wackiness where the engine would go out of bounds, then behavior would depend on what other things in memory it encountered when it did so.
I have mostly managed to fix up all the out-of-bounds issues, but this isn't enough to keep the demo's from desyncing (a similar issue applies with my Doom port).
Apparently, other engines like ZDoom and similar needed to do a bit of "heavy lifting" to get the demos from all of the various WAD versions to play without desync; as Doom was also dependent on the behavior of out-of-bounds memory accesses, and it was needed to turn these into in-bounds accesses (to larger memory objects) with the memory contents of the out-of-bounds accesses being faked.
Of course, the other option is just to "fix" the out-of-bounds accesses, and live with a port where the demo playback desyncs.
Meanwhile, Quake entirely avoided this issue:
The demo playback is based on recording the location and orientation of the player and any enemies at every point in time and similar, rather than based on recording and replaying the original sequence of keyboard inputs (and assuming that everything always happens exactly the same each time).
Then again, these sorts of issues are not unique to these games. Have watched more than a few speed-runs involving using glitches either to leave the playable parts of the map, or using convoluted sequences of actions to corrupt memory in such a way as to achieve a desired effect (such as triggering a warp to the end of the game).
Like, during normal gameplay, these games are seemingly just sorta corrupting memory all over the place but, for the most part, no one notices until something goes more obviously wrong...

     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.

C only requires at-least 64 bits.
I suspect in-practice, most code expects exactly 64 bits.

       ...
     ...

 

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 ?
 

Both options suck, granted.

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

I was not trying to claim that this idea wouldn't suck.
In my case, I went a different route that works a little better:
   Leaving all this stuff mostly up to software...