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