Path: ...!weretis.net!feeder8.news.weretis.net!feeder6.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: "Mini" tags to reduce the number of op codes
Date: Wed, 3 Apr 2024 21:53:26 +0000
Organization: Rocksolid Light
Message-ID: <e915303b53f3b4099ff254a4dcdfbe17@www.novabbs.org>
References: <uuk100$inj$1@dont-email.me> <uukduu$4o4p$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="4188873"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="PGd4t4cXnWwgUWG9VtTiCsm47oOWbHLcTr4rYoM0Edo";
User-Agent: Rocksolid Light
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
X-Rslight-Site: $2y$10$esq/jKpdUDnmSE7kqeCOguzQBw5twAVyRYsuHRyPrq1LcvOuVSnN6
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 4822
Lines: 96

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