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: <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> <veeso3$aq72$1@dont-email.me>
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.