Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail From: mitchalsup@aol.com (MitchAlsup1) Newsgroups: comp.arch Subject: Re: Tonights Tradeoff - Carry and Overflow Date: Sat, 12 Oct 2024 23:28:26 +0000 Organization: Rocksolid Light Message-ID: <531204abc9366f7dff2f288acb941f9a@www.novabbs.org> References: <37067f65c5982e4d03825b997b23c128@www.novabbs.org> <5f8ee3d3b2321ffa7e6c570882686b57@www.novabbs.org> <2024Oct4.081931@mips.complang.tuwien.ac.at> <2024Oct5.114309@mips.complang.tuwien.ac.at> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: i2pn2.org; logging-data="1769054"; mail-complaints-to="usenet@i2pn2.org"; posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU"; User-Agent: Rocksolid Light X-Rslight-Site: $2y$10$qpLMOTfE1.22dIE0UI4yhuJnL1aHJm81OlhlKsA/RR7EgCwALP2PC X-Spam-Checker-Version: SpamAssassin 4.0.0 X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71 Bytes: 5308 Lines: 98 On Sat, 12 Oct 2024 22:20:50 +0000, Robert Finch wrote: > On 2024-10-12 4:14 p.m., BGB wrote: >> On 10/12/2024 1:50 PM, MitchAlsup1 wrote: >>> On Sat, 12 Oct 2024 9:38:01 +0000, Robert Finch wrote: >>> >>>> On 2024-10-09 6:44 a.m., Robert Finch wrote: >>>> Mulled over carry and overflow in arithmetic operations. Looked at >>>> widening the datapath to 66-bits to hold carry and overflow bits. >>>> Thinking it may increase the size of the design by over 3% just to >>>> support carry and overflow. For now, an instruction, ADDGC, was added to >>>> generate the carry bit as a result. A 256-bit add looks like: >>>> >>>> ; 256 bit add >>>> ; A = r1,r2,r3,r4 >>>> ; B = r5,r6,r7,r8 >>>> ; S = r9,r10,r11,r12 >>>> >>>>     add r9,r1,r5,r0 >>>>     addgc r13,r1,r5,r0 >>>>     add r10,r2,r6,r13 >>>>     addgc r13,r2,r6,r13 >>>>     add r11,r7,r3,r13 >>>>     addgc r13,r7,r3,r13 >>>>     add r12,r8,r4,r13 >>> >>> My 66000 version:: >>> >>>        CARRY   R8,{{IO}{IO}{IO}{O}} >>>        ADD     R4,R12,R16 >>>        ADD     R5,R13,R17 >>>        ADD     R6,R14,R18 >>>        ADD     R7,R15,R19 >>>             // R{8,7,6,5,4} contain the 257-bit result. >>> >>> 256-bit add giving 257-bit result. >> >> BJX2 / XG2, assuming in-register (A/D=R4..R7, B=R20..R23): >>   CLRT >>   ADDC  R20, R4 >>   ADDC  R21, R5 >>   ADDC  R22, R6 >>   ADDC  R23, R7 >> >> Or, D=R16..R19 >>   MOV.X R4, R16 >>   MOV.X R6, R18 >>   CLRT >>   ADDC  R20, R16 >>   ADDC  R21, R17 >>   ADDC  R22, R18 >>   ADDC  R23, R19 >> >> ADDC is itself mostly a holdover from SH. >> >> Could almost make sense to make it have a 3R form though and move it to >> updating SR.S instead, since SR.T is likely better left exclusively to >> predication (vs mostly predication, and obscure edge-case ops like ADDC/ >> SUBC/ROTCL/...). >> >> Could almost add an ADDC.X op which operates 128 bits at a time, say: >>   CLRT >>   ADDC.X R4, R20, R16 >>   ADDC.X R6, R22, R18 >> >> Except that it would be rarely used enough to make its existence >> debatable at best. >> >> >>>> >>>> Not very elegant a solution, but it is simple. I think it requires >>>> minimal hardware. Three input ADD is already present and ADDGC just >>>> routes the carry bit to the output. >> > BJX2 / XG2 has destroys the value of the one source operand, I noted the > extra code to preserve the one operand. Is that only for the ADDC > instruction? > > What is the limit on the My66000 CARRY modifier for the number of > carries? Assuming the sequence is interruptible there must be a few bits > of state that need to be preserved. CARRY casts its modification over 8 subsequent instructions using its 16-bit immediate. > I found incorporating modifiers have a tendency to turn my code into > spaghetti. Maybe my grasp of implementation is not so great though. DECODE has a shift register to attach 2-bits to subsequent instructions each. However, the Rd provided by CARRY carries 64-bits from instruction to instruction--which makes 256×64 -bit multiplication straightforward. > The add, addgc can execute at the same time. So, it is 4 clocks at the > worst to add two 256-bit numbers. (The first / last instructions may > execute at the same time as other instructions). > I wanted to avoid using instruction modifiers and special flags > registers as much as possible. It is somewhat tricky to have a carry > flag in flight. Q+ is not very code dense, but the add can be done. It > is also possible to put the carry bit in a predicate register.