I've been wondering if a three-way add would be worth the bother
(and the opcode space), and I wrote a little Perl script to
go through the output of the current My 66000 compiler to find
opportunities.

The script is not 100% perfect, because it does not look at all
opportunities for adding if more than two add statements come in
sequence, and it does not detect adds that are not adjacent.
But it should be good enough for a general idea.

Results (numbers of positives, numbers of instructions,
percentage):

Perl: 1440 640291 0.225 %
gnuplot: 192 151402 0.127 %
embench-iot: 218 26405 0.826 %

By comparision, the number of fmac instructions:

Perl: 29
gnuplot: 1016
embench-iot: 29

So... not a great deal of instruction space to be saved, probably,
and I will refrain from advocating its inclusion in any ISA :-)

And here's the script:

#! /usr/bin/perl -w
$i = 0;
$n = 0;

while (<>) {
next unless /^\s[^.]/;
$i++;
next unless /^\s+add\s+(r[0-9]+),([^,]+),([^,]+)/;
$r1 = $1;
$next = <>;
if ($next =~ /\s+add\s+(r[0-9]+),-?([^,]+),-?([^,]+)/ )
{
if ($r1 eq $2 || $r1 eq $3) {
$n++;
}
}
}

printf ("%d %d %.3f %%\n", $n, $i, $n/$i*100.);

On Saturday, March 4, 2023 at 6:02:37 PM UTC-6, Thomas Koenig wrote:
<
> I've been wondering if a three-way add would be worth the bother
> (and the opcode space), and I wrote a little Perl script to
> go through the output of the current My 66000 compiler to find
> opportunities.
<
An interesting notion::
<
My 66000 AGEN is inherently a 3-input addition, and when one considers
<
CARRY R8,{I}
ADD R9,-R17,-R19
<
This is easier to code in Verilog as a 3-input adder than it is to code as
the first 3-bits being a 3-input adder and the other 61-bits being a 2-input
adder. All that you are doing is converting 61-3-input full adders into
2-input half-adders. Both 3-input full adders and 2-input adders are
2 gates of logic and 1 gate of delay.
<
Done are 3-input adder, one can get what Thomas was looking for done
using the above notation. The first multiprecision addition (or subtraction)
gets 63-bits from carry, and all subsequent carry outputs contain (0,1,2)-
bits. So, one can "get" 3-input integer adds using CARRY as a leading step.
<
..................
>
> The script is not 100% perfect, because it does not look at all
> opportunities for adding if more than two add statements come in
> sequence, and it does not detect adds that are not adjacent.
> But it should be good enough for a general idea.
<
Thanks for looking.
>
> Results (numbers of positives, numbers of instructions,
> percentage):
>
> Perl: 1440 640291 0.225 %
> gnuplot: 192 151402 0.127 %
> embench-iot: 218 26405 0.826 %
>
> By comparision, the number of fmac instructions:
>
> Perl: 29
> gnuplot: 1016
> embench-iot: 29
>
> So... not a great deal of instruction space to be saved, probably,
> and I will refrain from advocating its inclusion in any ISA :-)
>
> And here's the script:
>
> #! /usr/bin/perl -w
> $i = 0;
> $n = 0;
>
> while (<>) {
> next unless /^\s[^.]/;
> $i++;
> next unless /^\s+add\s+(r[0-9]+),([^,]+),([^,]+)/;
> $r1 = $1;
> $next = <>;
> if ($next =~ /\s+add\s+(r[0-9]+),-?([^,]+),-?([^,]+)/ )
> {
> if ($r1 eq $2 || $r1 eq $3) {
> $n++;
> }
> }
> }
>
> printf ("%d %d %.3f %%\n", $n, $i, $n/$i*100.);

Thomas Koenig <tkoenig@netcologne.de> writes:
>I've been wondering if a three-way add would be worth the bother
>(and the opcode space)

My memory told me that SuperSPARC supports three-way add, but looking
at
<https://vincyjoseph.files.wordpress.com/2013/04/supersparcwhitepaper.pdf>,
it actually supports two dependent integer ALU instructions in each cycle.

Similarly, Willamette and Northwood (the first two Pentium 4
generations) support two dependent integer ALU operation per cycle.

Prsecott (third generation Pentium 4) and AFAIK HyperSPARC (which
replaced SuperSPARC) did not have this feature, so apparently it was
not that important for performance (or it would have impacted cycle
time more than it would have helped IPC).

Implementationwise SuperSPARC used two ALUs for independent operations
followed by a crossbar followed by another two ALUs for the dependent
operation (so, given the total limit of three instructions per cycle,
there could be two ALU operations feeding one ALU operation or one ALU
operation feeding two ALU operations).

The Willamette/Northwood used two double-pumped ALUs, also on a
three-wide architecture, resulting in similar execution capabilities
as the SuperSPARC. I don't know if you could forward from one ALU to
the other every half-cycle. The data paths should be present (there
has to be forwarding every full cycle), so it probably could, but I
wonder if and how the timing worked out; after all, the Willamette and
Northwood were significantly higher clocked than the competition even
without double-pumping, how could they fit two (16-bit) ALU delays and
that much forwarding into one short cycle?

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Anton Ertl wrote:
>(the first two Pentium 4 generations) support two dependent integer ALU operation per cycle.

The Pentium 4 NetBurst architecture had double clock frequency on integer ALUs and half frequency on vector ALUs. In other words, an integer addition in general purpose registers was 4 times faster than an integer vector addition. The extraordinary high speed was obtained by making the adder staggered, which means that the upper half was added one clock cycle later than the lower half. Independent 64-bit additions could run at pipelined speed, while subsequent dependent additions had to wait an extra clock cycle. (This is discussed on p. 59 in my microarchitecture manual).

My ForwardCom instruction set has a 3-way addition instruction with option bits for sign change on each operand:
Y = ± A ± B ± C
I found that this instruction is very useful. The integer version executes in a single clock cycle. If you can do a 64-bit multiplication in ~3 clock cycles then you can also do two additions in one clock cycle because a multiplication involves many additions.

There is a problem with floating point 3-operand addition because the precision depends on the order of the operands. Maybe you need to take the two numerically largest operands first, or calculate the intermediate sum with very high precision.

On Saturday, March 18, 2023 at 4:05:35 AM UTC-5, Agner Fog wrote:
> Anton Ertl wrote:
> >(the first two Pentium 4 generations) support two dependent integer ALU operation per cycle.
> The Pentium 4 NetBurst architecture had double clock frequency on integer ALUs and half frequency on vector ALUs. In other words, an integer addition in general purpose registers was 4 times faster than an integer vector addition. The extraordinary high speed was obtained by making the adder staggered, which means that the upper half was added one clock cycle later than the lower half. Independent 64-bit additions could run at pipelined speed, while subsequent dependent additions had to wait an extra clock cycle. (This is discussed on p. 59 in my microarchitecture manual).
>
> My ForwardCom instruction set has a 3-way addition instruction with option bits for sign change on each operand:
> Y = ± A ± B ± C
> I found that this instruction is very useful. The integer version executes in a single clock cycle. If you can do a 64-bit multiplication in ~3 clock cycles then you can also do two additions in one clock cycle because a multiplication involves many additions.
<
¿integer multiplication? or the ¿multiplier tree? inside the FMAC unit ?
<
Some side effects::
Y = - A - B - C has a carry in of {3} and can have a carry out of {0, 1, 2}
>
> There is a problem with floating point 3-operand addition because the precision depends on the order of the operands. Maybe you need to take the two numerically largest operands first, or calculate the intermediate sum with very high precision.
<
There are 2 ways to utilize 3-operand FP addition::
a) Error Free Addition (IEEE 754 2019 call this Augmented Addition)
b) Three Way Sum
<
a) has several good properties:: none of the bits of {a, residule} overlap,
{a, residule} = {a,residule} + b is easy to calculate, and round.
(b) has none of these good properties.
<

On Saturday, March 18, 2023 at 4:05:35 AM UTC-5, Agner Fog wrote:
> Anton Ertl wrote:
> >(the first two Pentium 4 generations) support two dependent integer ALU operation per cycle.
<
> The Pentium 4 NetBurst architecture had double clock frequency on integer ALUs and half frequency on vector ALUs. In other words, an integer addition in general purpose registers was 4 times faster than an integer vector addition. The extraordinary high speed was obtained by making the adder staggered, which means that the upper half was added one clock cycle later than the lower half. Independent 64-bit additions could run at pipelined speed, while subsequent dependent additions had to wait an extra clock cycle. (This is discussed on p. 59 in my microarchitecture manual).
>
> My ForwardCom instruction set has a 3-way addition instruction with option bits for sign change on each operand:
> Y = ± A ± B ± C
> I found that this instruction is very useful. The integer version executes in a single clock cycle.
<
I just went through 100,000 lines of ASM out of Brian's compiler. I am finding Y = ± A ± B ± C
is way under 1% (probably near 0.2%*); not 1% of instructions executed, 1% of integer ADDs
executed. I ran into 3×-4× (i×j+k) IMAC than 3-operand adds.
{CoreMark, EMBencvh, LLVM front end, BLAS, Other Numerics, 560 subroutines}
>
Perhaps this is because my memory reference instructions operate under the
[Rbase+Rindex<<scale+Displacement] template, getting rid of most of the
need for 3-operand adds. I ran into 3×-4× (i×j+k) IMAC than 3-operand adds.
<
Nearly 1/4th of 3-operand ADDs want an immediate; I saw a range of {-257..+168}
<
> If you can do a 64-bit multiplication in ~3 clock cycles then you can also do two additions in one clock cycle because a multiplication involves many additions.
<
A 3-oprand ADD/SUB circuit is 2 gates delays longer than a 2-operand ADD/SUB.
However, a 3-operand ADD-scale is 1 gates shorter than your 3-operand ADD/SUB
and you don't do [Rb+Ri<<sc+Disp] Address generation !! Why ?
>
> There is a problem with floating point 3-operand addition because the precision depends on the order of the operands. Maybe you need to take the two numerically largest operands first, or calculate the intermediate sum with very high precision.

On Saturday, March 18, 2023 at 4:46:08 PM UTC-5, MitchAlsup wrote:
> On Saturday, March 18, 2023 at 4:05:35 AM UTC-5, Agner Fog wrote:
> > Anton Ertl wrote:
> > >(the first two Pentium 4 generations) support two dependent integer ALU operation per cycle.
> <
> > The Pentium 4 NetBurst architecture had double clock frequency on integer ALUs and half frequency on vector ALUs. In other words, an integer addition in general purpose registers was 4 times faster than an integer vector addition. The extraordinary high speed was obtained by making the adder staggered, which means that the upper half was added one clock cycle later than the lower half. Independent 64-bit additions could run at pipelined speed, while subsequent dependent additions had to wait an extra clock cycle. (This is discussed on p. 59 in my microarchitecture manual).
> >
> > My ForwardCom instruction set has a 3-way addition instruction with option bits for sign change on each operand:
> > Y = ± A ± B ± C
> > I found that this instruction is very useful. The integer version executes in a single clock cycle.
> <
> I just went through 100,000 lines of ASM out of Brian's compiler. I am finding Y = ± A ± B ± C
> is way under 1% (probably near 0.2%*); not 1% of instructions executed, 1% of integer ADDs
> executed. I ran into 3×-4× (i×j+k) IMAC than 3-operand adds.
> {CoreMark, EMBencvh, LLVM front end, BLAS, Other Numerics, 560 subroutines}
> >
> Perhaps this is because my memory reference instructions operate under the
> [Rbase+Rindex<<scale+Displacement] template, getting rid of most of the
> need for 3-operand adds. I ran into 3×-4× (i×j+k) IMAC than 3-operand adds.
> <
> Nearly 1/4th of 3-operand ADDs want an immediate; I saw a range of {-257...+168}
> <
> > If you can do a 64-bit multiplication in ~3 clock cycles then you can also do two additions in one clock cycle because a multiplication involves many additions.
> <
> A 3-oprand ADD/SUB circuit is 2 gates delays longer than a 2-operand ADD/SUB.
<----------------------------------------------------------------------------------
> However, a 3-operand ADD-scale is 1 gates shorter than your 3-operand ADD/SUB
> and you don't do [Rb+Ri<<sc+Disp] Address generation !! Why ?
<
I withdraw this question. And I especially withdraw the implied accusation.
Forward.com ISA certainly has this address mode.
<
Agner, I am sorry my memory is so flaky these days.
<------------------------------------------------------------------------------------
> >
> > There is a problem with floating point 3-operand addition because the precision depends on the order of the operands. Maybe you need to take the two numerically largest operands first, or calculate the intermediate sum with very high precision.

On 3/18/2023 2:05 AM, Agner Fog wrote:
> Anton Ertl wrote:
>> (the first two Pentium 4 generations) support two dependent integer ALU operation per cycle.
>
> The Pentium 4 NetBurst architecture had double clock frequency on integer ALUs and half frequency on vector ALUs. In other words, an integer addition in general purpose registers was 4 times faster than an integer vector addition. The extraordinary high speed was obtained by making the adder staggered, which means that the upper half was added one clock cycle later than the lower half. Independent 64-bit additions could run at pipelined speed, while subsequent dependent additions had to wait an extra clock cycle. (This is discussed on p. 59 in my microarchitecture manual).
>
> My ForwardCom instruction set has a 3-way addition instruction with option bits for sign change on each operand:
> Y = ± A ± B ± C
> I found that this instruction is very useful. The integer version executes in a single clock cycle. If you can do a 64-bit multiplication in ~3 clock cycles then you can also do two additions in one clock cycle because a multiplication involves many additions.
>
> There is a problem with floating point 3-operand addition because the precision depends on the order of the operands. Maybe you need to take the two numerically largest operands first, or calculate the intermediate sum with very high precision.

Comprehensive addressing has a three-operand add even without scaling:
A[i].f has base address, index, and immediate offset.

On Monday, March 20, 2023 at 7:37:08 AM UTC-5, Ivan Godard wrote:
> On 3/18/2023 2:05 AM, Agner Fog wrote:
> > Anton Ertl wrote:
> >> (the first two Pentium 4 generations) support two dependent integer ALU operation per cycle.
> >
> > The Pentium 4 NetBurst architecture had double clock frequency on integer ALUs and half frequency on vector ALUs. In other words, an integer addition in general purpose registers was 4 times faster than an integer vector addition. The extraordinary high speed was obtained by making the adder staggered, which means that the upper half was added one clock cycle later than the lower half. Independent 64-bit additions could run at pipelined speed, while subsequent dependent additions had to wait an extra clock cycle. (This is discussed on p. 59 in my microarchitecture manual).
> >
> > My ForwardCom instruction set has a 3-way addition instruction with option bits for sign change on each operand:
> > Y = ± A ± B ± C
> > I found that this instruction is very useful. The integer version executes in a single clock cycle. If you can do a 64-bit multiplication in ~3 clock cycles then you can also do two additions in one clock cycle because a multiplication involves many additions.
> >
> > There is a problem with floating point 3-operand addition because the precision depends on the order of the operands. Maybe you need to take the two numerically largest operands first, or calculate the intermediate sum with very high precision.
<
> Comprehensive addressing has a three-operand add even without scaling:
> A[i].f has base address, index, and immediate offset.
<
If A ends up being unresolved during the link process, it may also require an
indirection through GOT to get the address of the section containing A.