Path: ...!news.roellig-ltd.de!open-news-network.org!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.arch
Subject: Re: Tonights Tradeoff - Carry and Overflow
Date: Sat, 12 Oct 2024 15:14:36 -0500
Organization: A noiseless patient Spider
Lines: 71
Message-ID: <veelbd$9gnd$2@dont-email.me>
References: <vbgdms$152jq$1@dont-email.me> <vbog6d$2p2rc$1@dont-email.me>
 <f2d99c60ba76af28c8b63b9628fb56fa@www.novabbs.org>
 <vc61e6$21skv$1@dont-email.me> <vc8gl4$2m5tp$1@dont-email.me>
 <vcv5uj$3arh6$1@dont-email.me>
 <37067f65c5982e4d03825b997b23c128@www.novabbs.org>
 <vd352q$3s1e$1@dont-email.me>
 <5f8ee3d3b2321ffa7e6c570882686b57@www.novabbs.org>
 <vd6a5e$o0aj$2@dont-email.me> <vdnpg4$3c9e$2@dont-email.me>
 <2024Oct4.081931@mips.complang.tuwien.ac.at> <vdp343$9d38$1@dont-email.me>
 <2024Oct5.114309@mips.complang.tuwien.ac.at> <ve5mpq$2jt5k$1@dont-email.me>
 <vedg1s$43mp$1@dont-email.me>
 <ebe5b174d1e95801af623a450c464504@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 12 Oct 2024 22:14:38 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="49ba8ae5553edb0f18c63300f704f6f1";
	logging-data="312045"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+2GzgT6MCvn7nrosZ2zgl3CvlvwFdEkzo="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:4eRZyBkmRqNpSzSVIQQ+iTaLsvQ=
In-Reply-To: <ebe5b174d1e95801af623a450c464504@www.novabbs.org>
Content-Language: en-US
Bytes: 3832

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.