Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Robert Finch <robfi680@gmail.com>
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: <veeso3$aq72$1@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>
 <veelbd$9gnd$2@dont-email.me>
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: <veelbd$9gnd$2@dont-email.me>
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.