Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Robert Finch Newsgroups: comp.arch Subject: Re: Tonights Tradeoff - Carry and Overflow Date: Sat, 12 Oct 2024 18:20:50 -0400 Organization: A noiseless patient Spider Lines: 91 Message-ID: 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-Date: Sun, 13 Oct 2024 00:20:51 +0200 (CEST) Injection-Info: dont-email.me; posting-host="29fc730c4615fe70a51db70f860a30da"; logging-data="354530"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19q3u5H/mdnkp1STQeKX4aeaCJQaj0XTMU=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:LwKlFMOBbLcIqbVZZZD/QKnlEto= In-Reply-To: Content-Language: en-US Bytes: 4896 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. I found incorporating modifiers have a tendency to turn my code into spaghetti. Maybe my grasp of implementation is not so great though. 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.