On Tuesday, November 9, 2021 at 5:05:03 PM UTC-6, Ivan Godard wrote:
> On 11/9/2021 1:26 PM, MitchAlsup wrote:
> > On Tuesday, November 9, 2021 at 1:21:29 PM UTC-6, Stefan Monnier wrote:
> >> MitchAlsup [2021-11-09 08:11:06] wrote:
> >>> On Tuesday, November 9, 2021 at 7:30:35 AM UTC-6, Stefan Monnier wrote:
> >>>> Reminds me of a question: IIUC, the MADD instruction will typically have
> >>>> a latency of a few cycles (let's say 3) but the latency of the signal
> >>>> is not the same for all 3 inputs. More specifically, IIUC the 3rd
> >>>> ("carry") input can arrive as late as the last cycle without impacting
> >>>> the overall latency.
> >>>>
> >>>> This means that in theory we can have a sequence of MADD instructions
> >>>> all accumulating into the same register at a rate of 1 per cycle
> >>>> (assuming the unit is pipelined), but if all inputs are "read" at
> >>>> the same time, then the rate goes down to 1/3 per cycle.
> >>>>
> >>>> How do OoO cores avoid this throughput problem?
> >>> We build the function unit to accept all 3 operands on the same clock.
> >>> Then we don't use the 3rd operand until "later"
> >> IOW you don't avoid this throughput problem?
> >> I mean:
> >>
> >> accum1 = MADD(x1, x2, accum);
> >> accum2 = MADD(x3, x4, accum1);
> >>
> >> ends up with a latency of 2*N cycles instead of N+1, right?
> > <
> > Yes,
> > <
> >> Because we can't start the second MADD before the first is over :-(
> > <
> > Yes,
> > <
> > But as long as you do not exceed the size of the execution window,
> > it all works; you can put new instructions into the window every
> > cycle, you can retire instructions from the window every cycle,
> > and each function units can start a calculation every cycle. All
> > without SW having to schedule the code or to apply any Herculean
> > effort in code selection.
> Except for reduction and other inter-instruction data dependencies. Then
> you pay the full latency.
<
So does essentially everybody.
<
It was not until the invention of the quire that reduction arithmetic
became modern.

On 11/9/2021 3:26 PM, MitchAlsup wrote:
> On Tuesday, November 9, 2021 at 5:05:03 PM UTC-6, Ivan Godard wrote:
>> On 11/9/2021 1:26 PM, MitchAlsup wrote:
>>> On Tuesday, November 9, 2021 at 1:21:29 PM UTC-6, Stefan Monnier wrote:
>>>> MitchAlsup [2021-11-09 08:11:06] wrote:
>>>>> On Tuesday, November 9, 2021 at 7:30:35 AM UTC-6, Stefan Monnier wrote:
>>>>>> Reminds me of a question: IIUC, the MADD instruction will typically have
>>>>>> a latency of a few cycles (let's say 3) but the latency of the signal
>>>>>> is not the same for all 3 inputs. More specifically, IIUC the 3rd
>>>>>> ("carry") input can arrive as late as the last cycle without impacting
>>>>>> the overall latency.
>>>>>>
>>>>>> This means that in theory we can have a sequence of MADD instructions
>>>>>> all accumulating into the same register at a rate of 1 per cycle
>>>>>> (assuming the unit is pipelined), but if all inputs are "read" at
>>>>>> the same time, then the rate goes down to 1/3 per cycle.
>>>>>>
>>>>>> How do OoO cores avoid this throughput problem?
>>>>> We build the function unit to accept all 3 operands on the same clock.
>>>>> Then we don't use the 3rd operand until "later"
>>>> IOW you don't avoid this throughput problem?
>>>> I mean:
>>>>
>>>> accum1 = MADD(x1, x2, accum);
>>>> accum2 = MADD(x3, x4, accum1);
>>>>
>>>> ends up with a latency of 2*N cycles instead of N+1, right?
>>> <
>>> Yes,
>>> <
>>>> Because we can't start the second MADD before the first is over :-(
>>> <
>>> Yes,
>>> <
>>> But as long as you do not exceed the size of the execution window,
>>> it all works; you can put new instructions into the window every
>>> cycle, you can retire instructions from the window every cycle,
>>> and each function units can start a calculation every cycle. All
>>> without SW having to schedule the code or to apply any Herculean
>>> effort in code selection.
>> Except for reduction and other inter-instruction data dependencies. Then
>> you pay the full latency.
> <
> So does essentially everybody.
> <
> It was not until the invention of the quire that reduction arithmetic
> became modern.
>

Please forgive my ignorance, but what's a "quire" in this context?

On Tuesday, November 9, 2021 at 5:58:33 PM UTC-6, Ivan Godard wrote:
> On 11/9/2021 3:26 PM, MitchAlsup wrote:
> > On Tuesday, November 9, 2021 at 5:05:03 PM UTC-6, Ivan Godard wrote:
> >> On 11/9/2021 1:26 PM, MitchAlsup wrote:
> >>> On Tuesday, November 9, 2021 at 1:21:29 PM UTC-6, Stefan Monnier wrote:
> >>>> MitchAlsup [2021-11-09 08:11:06] wrote:
> >>>>> On Tuesday, November 9, 2021 at 7:30:35 AM UTC-6, Stefan Monnier wrote:
> >>>>>> Reminds me of a question: IIUC, the MADD instruction will typically have
> >>>>>> a latency of a few cycles (let's say 3) but the latency of the signal
> >>>>>> is not the same for all 3 inputs. More specifically, IIUC the 3rd
> >>>>>> ("carry") input can arrive as late as the last cycle without impacting
> >>>>>> the overall latency.
> >>>>>>
> >>>>>> This means that in theory we can have a sequence of MADD instructions
> >>>>>> all accumulating into the same register at a rate of 1 per cycle
> >>>>>> (assuming the unit is pipelined), but if all inputs are "read" at
> >>>>>> the same time, then the rate goes down to 1/3 per cycle.
> >>>>>>
> >>>>>> How do OoO cores avoid this throughput problem?
> >>>>> We build the function unit to accept all 3 operands on the same clock.
> >>>>> Then we don't use the 3rd operand until "later"
> >>>> IOW you don't avoid this throughput problem?
> >>>> I mean:
> >>>>
> >>>> accum1 = MADD(x1, x2, accum);
> >>>> accum2 = MADD(x3, x4, accum1);
> >>>>
> >>>> ends up with a latency of 2*N cycles instead of N+1, right?
> >>> <
> >>> Yes,
> >>> <
> >>>> Because we can't start the second MADD before the first is over :-(
> >>> <
> >>> Yes,
> >>> <
> >>> But as long as you do not exceed the size of the execution window,
> >>> it all works; you can put new instructions into the window every
> >>> cycle, you can retire instructions from the window every cycle,
> >>> and each function units can start a calculation every cycle. All
> >>> without SW having to schedule the code or to apply any Herculean
> >>> effort in code selection.
> >> Except for reduction and other inter-instruction data dependencies. Then
> >> you pay the full latency.
> > <
> > So does essentially everybody.
> > <
> > It was not until the invention of the quire that reduction arithmetic
> > became modern.
> >
> Please forgive my ignorance, but what's a "quire" in this context?
<
quire is the error free accumulator designed into posits. It is as long
as required to be able to accumulate any result calculated and not
loose a single bit of precision (2048 for posit effective double)
<
We (they actually) could do something similar for 754..........costing
2100 bits in IEEE double (since you have to account for denorms)

MitchAlsup wrote:
> On Tuesday, November 9, 2021 at 5:58:33 PM UTC-6, Ivan Godard wrote:
>> On 11/9/2021 3:26 PM, MitchAlsup wrote:
>>> On Tuesday, November 9, 2021 at 5:05:03 PM UTC-6, Ivan Godard wrote:
>>>> On 11/9/2021 1:26 PM, MitchAlsup wrote:
>>>>> On Tuesday, November 9, 2021 at 1:21:29 PM UTC-6, Stefan Monnier wrote:
>>>>>> MitchAlsup [2021-11-09 08:11:06] wrote:
>>>>>>> On Tuesday, November 9, 2021 at 7:30:35 AM UTC-6, Stefan Monnier wrote:
>>>>>>>> Reminds me of a question: IIUC, the MADD instruction will typically have
>>>>>>>> a latency of a few cycles (let's say 3) but the latency of the signal
>>>>>>>> is not the same for all 3 inputs. More specifically, IIUC the 3rd
>>>>>>>> ("carry") input can arrive as late as the last cycle without impacting
>>>>>>>> the overall latency.
>>>>>>>>
>>>>>>>> This means that in theory we can have a sequence of MADD instructions
>>>>>>>> all accumulating into the same register at a rate of 1 per cycle
>>>>>>>> (assuming the unit is pipelined), but if all inputs are "read" at
>>>>>>>> the same time, then the rate goes down to 1/3 per cycle.
>>>>>>>>
>>>>>>>> How do OoO cores avoid this throughput problem?
>>>>>>> We build the function unit to accept all 3 operands on the same clock.
>>>>>>> Then we don't use the 3rd operand until "later"
>>>>>> IOW you don't avoid this throughput problem?
>>>>>> I mean:
>>>>>>
>>>>>> accum1 = MADD(x1, x2, accum);
>>>>>> accum2 = MADD(x3, x4, accum1);
>>>>>>
>>>>>> ends up with a latency of 2*N cycles instead of N+1, right?
>>>>> <
>>>>> Yes,
>>>>> <
>>>>>> Because we can't start the second MADD before the first is over :-(
>>>>> <
>>>>> Yes,
>>>>> <
>>>>> But as long as you do not exceed the size of the execution window,
>>>>> it all works; you can put new instructions into the window every
>>>>> cycle, you can retire instructions from the window every cycle,
>>>>> and each function units can start a calculation every cycle. All
>>>>> without SW having to schedule the code or to apply any Herculean
>>>>> effort in code selection.
>>>> Except for reduction and other inter-instruction data dependencies. Then
>>>> you pay the full latency.
>>> <
>>> So does essentially everybody.
>>> <
>>> It was not until the invention of the quire that reduction arithmetic
>>> became modern.
>>>
>> Please forgive my ignorance, but what's a "quire" in this context?
> <
> quire is the error free accumulator designed into posits. It is as long
> as required to be able to accumulate any result calculated and not
> loose a single bit of precision (2048 for posit effective double)
> <
> We (they actually) could do something similar for 754..........costing
> 2100 bits in IEEE double (since you have to account for denorms)
>
We have discussed this many times here, afair always using the
SuperAccumulator term?

The key is that with carry-save/redundant storage, it becomes trivial to
accept one or more updates every cycle: Each full adder is just 2 or 3
gate delays, right?

If I was targeting just one update/cycle I would probably work in
multi-bit (8?) bit chunks with additional carry storage only at the
boundaries.

Actually extracting and rounding the final result requires an FF1
circuit that covers the entire array, a way to extract ~55/114 bits from
that point on and a circuit to OR together all trailing bits.

If the accumulator is stored as bytes, then you can just grab the 8 or
16 bytes that encompasses the target mantissa and shift it down by 0-7
bits, that seems very doable, while the tail end zero/non-zero detector
can be OR'ed into the bottom bit.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

MitchAlsup [2021-11-09 14:30:32] wrote:
> On Tuesday, November 9, 2021 at 4:04:05 PM UTC-6, Stefan Monnier wrote:
>> >> For integers, we can replace the code with;
>> >>
>> >> x12 = MUL(x1, x2);
>> >> x34 = MUL(x3, x4);
>> >> accum1 = ADD(x12, accum);
>> >> accum2 = ADD(x34, accum1);
>> >>
>> >> with latency N+2, which is likely better than 2*N.
>> > <
>> > Given the IMUL takes 3 cycles, the count is N+3;
>> > accum1 = cannot begin until x12 = MUL completes.
>> I don't understand. My "N" was the latency of MUL (and MADD).
>> So with your N=3 it means the MADD version takes 6 cycles whiles the
>> MUL+ADD version only takes 5.
> <
> +----------+----------+----------+----------+----------+
> | cycle 1| cycle2|cycle 3|cycle 4|cycle 5|
> +----------+----------+----------+----------+----------+
> Cycle 1 MUL x12 begins
> Cycle 2 MUL x23 begins
> Cycle 3 no instruction gets launched
> Cycle 4 1st ADD begins MUL x12 forwards to ADD
> Cycle 5 2nd Add begins 1st Add ends MUL x34 forwards to ADDs
> Cycle 6 2nd ADD ends

So we agree: the MUL+ADD version has lower latency than the MADD version?

Stefan

> So we agree: the MUL+ADD version has lower latency than the MADD version?

I find this disappointing: I thought non-legacy architectures wouldn't
suffer from such cases where a "complex" instruction results in slower
code than its decomposition into its constituent simpler operations.

I suspect that for FPMADD the problem doesn't occur because FPADD isn't
cheap (which both means that the decomposed code will be slower, and
also that even if we tried to be super-extra careful about scheduling,
FPMADD wouldn't be able to delay reading its third argument as much as
MADD would (it's not just a matter of stuffing the bits into a carry
save adder but you also need to first shift/align them according to the
exponent)).

Stefan

On Wednesday, November 10, 2021 at 2:48:34 AM UTC-6, Terje Mathisen wrote:
> MitchAlsup wrote:
> > On Tuesday, November 9, 2021 at 5:58:33 PM UTC-6, Ivan Godard wrote:
> >> On 11/9/2021 3:26 PM, MitchAlsup wrote:
> >>> On Tuesday, November 9, 2021 at 5:05:03 PM UTC-6, Ivan Godard wrote:
> >>>> On 11/9/2021 1:26 PM, MitchAlsup wrote:
> >>>>> On Tuesday, November 9, 2021 at 1:21:29 PM UTC-6, Stefan Monnier wrote:
> >>>>>> MitchAlsup [2021-11-09 08:11:06] wrote:
> >>>>>>> On Tuesday, November 9, 2021 at 7:30:35 AM UTC-6, Stefan Monnier wrote:
> >>>>>>>> Reminds me of a question: IIUC, the MADD instruction will typically have
> >>>>>>>> a latency of a few cycles (let's say 3) but the latency of the signal
> >>>>>>>> is not the same for all 3 inputs. More specifically, IIUC the 3rd
> >>>>>>>> ("carry") input can arrive as late as the last cycle without impacting
> >>>>>>>> the overall latency.
> >>>>>>>>
> >>>>>>>> This means that in theory we can have a sequence of MADD instructions
> >>>>>>>> all accumulating into the same register at a rate of 1 per cycle
> >>>>>>>> (assuming the unit is pipelined), but if all inputs are "read" at
> >>>>>>>> the same time, then the rate goes down to 1/3 per cycle.
> >>>>>>>>
> >>>>>>>> How do OoO cores avoid this throughput problem?
> >>>>>>> We build the function unit to accept all 3 operands on the same clock.
> >>>>>>> Then we don't use the 3rd operand until "later"
> >>>>>> IOW you don't avoid this throughput problem?
> >>>>>> I mean:
> >>>>>>
> >>>>>> accum1 = MADD(x1, x2, accum);
> >>>>>> accum2 = MADD(x3, x4, accum1);
> >>>>>>
> >>>>>> ends up with a latency of 2*N cycles instead of N+1, right?
> >>>>> <
> >>>>> Yes,
> >>>>> <
> >>>>>> Because we can't start the second MADD before the first is over :-(
> >>>>> <
> >>>>> Yes,
> >>>>> <
> >>>>> But as long as you do not exceed the size of the execution window,
> >>>>> it all works; you can put new instructions into the window every
> >>>>> cycle, you can retire instructions from the window every cycle,
> >>>>> and each function units can start a calculation every cycle. All
> >>>>> without SW having to schedule the code or to apply any Herculean
> >>>>> effort in code selection.
> >>>> Except for reduction and other inter-instruction data dependencies. Then
> >>>> you pay the full latency.
> >>> <
> >>> So does essentially everybody.
> >>> <
> >>> It was not until the invention of the quire that reduction arithmetic
> >>> became modern.
> >>>
> >> Please forgive my ignorance, but what's a "quire" in this context?
> > <
> > quire is the error free accumulator designed into posits. It is as long
> > as required to be able to accumulate any result calculated and not
> > loose a single bit of precision (2048 for posit effective double)
> > <
> > We (they actually) could do something similar for 754..........costing
> > 2100 bits in IEEE double (since you have to account for denorms)
> >
> We have discussed this many times here, afair always using the
> SuperAccumulator term?
>
> The key is that with carry-save/redundant storage, it becomes trivial to
> accept one or more updates every cycle: Each full adder is just 2 or 3
> gate delays, right?
<
A single 3-2 counter is 1 gate of delay.
A single 4-2 compressor is 2-gates of delay.
So, basically, you can add as many things into the accumulator as you
can afford to route to the accumulator. Certainly 8 lanes per cycle is
reasonable.
>
> If I was targeting just one update/cycle I would probably work in
> multi-bit (8?) bit chunks with additional carry storage only at the
> boundaries.
>
> Actually extracting and rounding the final result requires an FF1
> circuit that covers the entire array, a way to extract ~55/114 bits from
> that point on and a circuit to OR together all trailing bits.
<
In general, it is fairly easy to remember where the HoB is.
In general, assembling the sticky bit is only a few gates of delay (5-ish)
>
> If the accumulator is stored as bytes, then you can just grab the 8 or
> 16 bytes that encompasses the target mantissa and shift it down by 0-7
> bits, that seems very doable, while the tail end zero/non-zero detector
> can be OR'ed into the bottom bit.
<
The posit guys suggest a model where one accesses the quire as an array in
memory, accessing 2 quadwords per accumulation based on the exponent
of the intermediate augend.
<
> Terje
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

On Wednesday, November 10, 2021 at 9:18:36 AM UTC-6, Stefan Monnier wrote:
> > So we agree: the MUL+ADD version has lower latency than the MADD version?
> I find this disappointing: I thought non-legacy architectures wouldn't
> suffer from such cases where a "complex" instruction results in slower
> code than its decomposition into its constituent simpler operations.
>
> I suspect that for FPMADD the problem doesn't occur because FPADD isn't
> cheap (which both means that the decomposed code will be slower, and
> also that even if we tried to be super-extra careful about scheduling,
> FPMADD wouldn't be able to delay reading its third argument as much as
> MADD would (it's not just a matter of stuffing the bits into a carry
> save adder but you also need to first shift/align them according to the
> exponent)).
<
Integer MAC has the property that no bits have been lost.
Floating MAC has the property of both the multiply and the add are performed
prior to any rounding (rounding=loss in precision).
<
So while IMAC can be done as 2 instructions; FMAC cannot.
>
>
> Stefan

MitchAlsup wrote:
> On Wednesday, November 10, 2021 at 2:48:34 AM UTC-6, Terje Mathisen wrote:
>> Actually extracting and rounding the final result requires an FF1
>> circuit that covers the entire array, a way to extract ~55/114 bits from
>> that point on and a circuit to OR together all trailing bits.
> <
> In general, it is fairly easy to remember where the HoB is.
> In general, assembling the sticky bit is only a few gates of delay (5-ish)
>>
Sticky is just a wide zero/non-zero detector, right?

>> If the accumulator is stored as bytes, then you can just grab the 8 or
>> 16 bytes that encompasses the target mantissa and shift it down by 0-7
>> bits, that seems very doable, while the tail end zero/non-zero detector
>> can be OR'ed into the bottom bit.
> <
> The posit guys suggest a model where one accesses the quire as an array in
> memory, accessing 2 quadwords per accumulation based on the exponent
> of the intermediate augend.

If I had to implement it in SW, I'm guessing that an approach which
allows delayed carry updates would be nice.

I.e. something like 48 bits stored in each 64-bit block, each addition
splits the input into two parts based on the exponent, and we can
blindly add up to 65535 entries before we have to propagate the carries,
i.e. usually just a single iteration of this at the end?

Using 50% storage (32 bits in each 64-bit word) would make the alignment
slightly faster.

It would also be possible to let each block be either positive or
negative, with just a very small increase in the final carry/overflow
propagation.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Stefan Monnier <monnier@iro.umontreal.ca> schrieb:
> MitchAlsup [2021-11-09 08:11:06] wrote:
>> On Tuesday, November 9, 2021 at 7:30:35 AM UTC-6, Stefan Monnier wrote:
>>> Reminds me of a question: IIUC, the MADD instruction will typically have
>>> a latency of a few cycles (let's say 3) but the latency of the signal
>>> is not the same for all 3 inputs. More specifically, IIUC the 3rd
>>> ("carry") input can arrive as late as the last cycle without impacting
>>> the overall latency.
>>>
>>> This means that in theory we can have a sequence of MADD instructions
>>> all accumulating into the same register at a rate of 1 per cycle
>>> (assuming the unit is pipelined), but if all inputs are "read" at
>>> the same time, then the rate goes down to 1/3 per cycle.
>>>
>>> How do OoO cores avoid this throughput problem?
>> We build the function unit to accept all 3 operands on the same clock.
>> Then we don't use the 3rd operand until "later"
>
> IOW you don't avoid this throughput problem?
> I mean:
>
> accum1 = MADD(x1, x2, accum);
> accum2 = MADD(x3, x4, accum1);
>
> ends up with a latency of 2*N cycles instead of N+1, right?
> Because we can't start the second MADD before the first is over :-(

Depends, I think.

The most likely use case is going to be multiplication of
long integers for crypto. For this, you will need access
to the low and high part of the result, and you will
need another add. Let's also assume that the
architecture has separate high and low multiply + adds.

So, looking at the pseudocode that Mitch recently posted:

{mcarry, product} = multiplicand[i]*multiplier[j]
+ mcarry;
{acarry,sum[i+j]} = {sum[i+j]+acarry} + product;

with i the inner loop and J in a register. This would
then translate to (roughly)

LD Rmi, R_mulitiplicand + i << 8
LD Rs_ij, R_sum
MADD R_product, R_mi, R_mcarry
MADDH R_mcarry, R_mi, R_mcarry
ADD R_temp, Rs_ij, R_acarry ! Sets a carry
ADDC R_acarry, #0 ! Increment if carry set
ADD R_sum, R_temp, R_product ! Sets a carry
ST Rs_ij, R_sum
ADDC R_acarry, #0 ! Increment if carry set

The summation is a bit awkward (if I have that right), but there
is an advantage in using the multiply+add, as the latency is used
up by other instructions.

On Friday, November 12, 2021 at 12:53:10 AM UTC-6, Thomas Koenig wrote:
> Stefan Monnier <mon...@iro.umontreal.ca> schrieb:
> > MitchAlsup [2021-11-09 08:11:06] wrote:
> >> On Tuesday, November 9, 2021 at 7:30:35 AM UTC-6, Stefan Monnier wrote:
> >>> Reminds me of a question: IIUC, the MADD instruction will typically have
> >>> a latency of a few cycles (let's say 3) but the latency of the signal
> >>> is not the same for all 3 inputs. More specifically, IIUC the 3rd
> >>> ("carry") input can arrive as late as the last cycle without impacting
> >>> the overall latency.
> >>>
> >>> This means that in theory we can have a sequence of MADD instructions
> >>> all accumulating into the same register at a rate of 1 per cycle
> >>> (assuming the unit is pipelined), but if all inputs are "read" at
> >>> the same time, then the rate goes down to 1/3 per cycle.
> >>>
> >>> How do OoO cores avoid this throughput problem?
> >> We build the function unit to accept all 3 operands on the same clock.
> >> Then we don't use the 3rd operand until "later"
> >
> > IOW you don't avoid this throughput problem?
> > I mean:
> >
> > accum1 = MADD(x1, x2, accum);
> > accum2 = MADD(x3, x4, accum1);
> >
> > ends up with a latency of 2*N cycles instead of N+1, right?
> > Because we can't start the second MADD before the first is over :-(
> Depends, I think.
>
> The most likely use case is going to be multiplication of
> long integers for crypto. For this, you will need access
> to the low and high part of the result, and you will
> need another add. Let's also assume that the
> architecture has separate high and low multiply + adds.
>
> So, looking at the pseudocode that Mitch recently posted:
>
> {mcarry, product} = multiplicand[i]*multiplier[j]
> + mcarry;
> {acarry,sum[i+j]} = {sum[i+j]+acarry} + product;
>
> with i the inner loop and J in a register. This would
> then translate to (roughly)
>
> LD Rmi, R_mulitiplicand + i << 8
> LD Rs_ij, R_sum
> MADD R_product, R_mi, R_mcarry
> MADDH R_mcarry, R_mi, R_mcarry
> ADD R_temp, Rs_ij, R_acarry ! Sets a carry
> ADDC R_acarry, #0 ! Increment if carry set
> ADD R_sum, R_temp, R_product ! Sets a carry
> ST Rs_ij, R_sum
> ADDC R_acarry, #0 ! Increment if carry set
<
< then translate to (exactly)
ADD Rij,Ri,Rj // you seem to have missed this
LDD Rmc,[Rmpc+Rj<<3] // multiplicand[i]
LDD Rsm,[Rsmp+Rij<<3] // sum[i+j]
CARRY Rcm,{IO}
MUL Rpr,Rmp,Rmc // MAC {Rcm,Rpr},{Rmp,Rcm},Rmc
CARRY Rca,{IO}
ADD Rsum,Rsum,Rpr // ADC {Rca,Rsum},{Rsum,Rca},Rpr
STD Rsum,[Rsum+Rij<<3] // sum[i+j]
<
>
> The summation is a bit awkward (if I have that right), but there
> is an advantage in using the multiply+add, as the latency is used
> up by other instructions.