On Tuesday, November 22, 2022 at 5:36:11 PM UTC, MitchAlsup wrote:

> Something the readers should be aware of:: Saturation makes the
> arithmetic slower (by about 2 gates) because adders are set up to
> wrap. Saturation requires the detection of wrap (easy enough) and
> then the output of the adder basically has to go through a 3-way
> multiplexer that chooses from {lbound, result, ubound}. So, you may
> have just made your frequency lower by 5%-6%.

what about passing that to the next stage (after the add,
just before write-to-regfile)? a post-analysis was what i
was planning in the implementation of SVP64: pass enough
from an *unmodified* pipeline to an augmented CCode step.

given that Power ISA already has CCs (EQ,LT,GT) and Carry-in
and Carry-out i am not feeling it to be unreasonable.

l.

On Sunday, May 14, 2023 at 12:45:22 PM UTC-5, luke.l...@gmail.com wrote:
> On Tuesday, November 22, 2022 at 5:36:11 PM UTC, MitchAlsup wrote:
>
> > Something the readers should be aware of:: Saturation makes the
> > arithmetic slower (by about 2 gates) because adders are set up to
> > wrap. Saturation requires the detection of wrap (easy enough) and
> > then the output of the adder basically has to go through a 3-way
> > multiplexer that chooses from {lbound, result, ubound}. So, you may
> > have just made your frequency lower by 5%-6%.
<
> what about passing that to the next stage (after the add,
> just before write-to-regfile)? a post-analysis was what i
> was planning in the implementation of SVP64: pass enough
> from an *unmodified* pipeline to an augmented CCode step.
<
If you pass the saturation off until the cycle after addition, you cannot
use the result in the subsequent cycle--but only in the subsequent
subsequent cycle (latency = 2).
>
> given that Power ISA already has CCs (EQ,LT,GT) and Carry-in
> and Carry-out i am not feeling it to be unreasonable.
>
> l.

On Sunday, May 14, 2023 at 10:02:18 PM UTC+1, MitchAlsup wrote:
> On Sunday, May 14, 2023 at 12:45:22 PM UTC-5, luke.l...@gmail.com wrote:
> > On Tuesday, November 22, 2022 at 5:36:11 PM UTC, MitchAlsup wrote:
> >
> > > Something the readers should be aware of:: Saturation makes the
> > > arithmetic slower (by about 2 gates) because adders are set up to
> > > wrap. Saturation requires the detection of wrap (easy enough) and
> > > then the output of the adder basically has to go through a 3-way
> > > multiplexer that chooses from {lbound, result, ubound}. So, you may
> > > have just made your frequency lower by 5%-6%.
> <
> > what about passing that to the next stage (after the add,
> > just before write-to-regfile)? a post-analysis was what i
> > was planning in the implementation of SVP64: pass enough
> > from an *unmodified* pipeline to an augmented CCode step.
> <
> If you pass the saturation off until the cycle after addition, you cannot
> use the result in the subsequent cycle--but only in the subsequent
> subsequent cycle (latency = 2).

is it _really_ that much more complex than Condition-Codes?
(if so i don't mind that 5%-6% but others might, and i am designing
an ISA that is general-purpose rather than academic, so
i am taking the 5-6% seriously)

i guess it is. where Condition-Codes are simply additional output,
if we may reasonably say that "If Carry-Out that means saturate",
then saturation *changes* the output based on what Carry-out is
set to.

as one of the inputs to the 3-way Mux.

hmmm...

this probably goes a long way towards explaining why Power ISA
cores do not get ramped up to the same 4.8 ghz that everyone
else aims for. instead the max clock rate is around 3.0 ghz even
in 7 nm but IBM make up for it by doing massive-wide issue and
doing I/O bandwidth far in excess of x86.

l.

On Monday, May 15, 2023 at 8:59:12 PM UTC-5, luke.l...@gmail.com wrote:
> On Sunday, May 14, 2023 at 10:02:18 PM UTC+1, MitchAlsup wrote:
> > On Sunday, May 14, 2023 at 12:45:22 PM UTC-5, luke.l...@gmail.com wrote:
> > > On Tuesday, November 22, 2022 at 5:36:11 PM UTC, MitchAlsup wrote:
> > >
> > > > Something the readers should be aware of:: Saturation makes the
> > > > arithmetic slower (by about 2 gates) because adders are set up to
> > > > wrap. Saturation requires the detection of wrap (easy enough) and
> > > > then the output of the adder basically has to go through a 3-way
> > > > multiplexer that chooses from {lbound, result, ubound}. So, you may
> > > > have just made your frequency lower by 5%-6%.
> > <
> > > what about passing that to the next stage (after the add,
> > > just before write-to-regfile)? a post-analysis was what i
> > > was planning in the implementation of SVP64: pass enough
> > > from an *unmodified* pipeline to an augmented CCode step.
> > <
> > If you pass the saturation off until the cycle after addition, you cannot
> > use the result in the subsequent cycle--but only in the subsequent
> > subsequent cycle (latency = 2).
<
> is it _really_ that much more complex than Condition-Codes?
<
It is, in essence, a 3-input data-width multiplexer where the input
to the data is the output of the adder and the control input is the
condition code. The delay is very much more fan-up and wire
than logic gates.
<
Another way to look at it is that it is a second carry chain after
the primary carry chain.
<
> (if so i don't mind that 5%-6% but others might, and i am designing
> an ISA that is general-purpose rather than academic, so
> i am taking the 5-6% seriously)
<
So, make integer stuff 1 cycle and saturating stuff 2-cycles by
"pipelining away" the added latency.
>
> i guess it is. where Condition-Codes are simply additional output,
> if we may reasonably say that "If Carry-Out that means saturate",
> then saturation *changes* the output based on what Carry-out is
> set to.
>
> as one of the inputs to the 3-way Mux.
>
> hmmm...
<
See, now you are getting it; grasshopper.
>
> this probably goes a long way towards explaining why Power ISA
> cores do not get ramped up to the same 4.8 ghz that everyone
> else aims for. instead the max clock rate is around 3.0 ghz even
> in 7 nm but IBM make up for it by doing massive-wide issue and
> doing I/O bandwidth far in excess of x86.
>
> l.

On 2023-05-14, MitchAlsup wrote:
> On Sunday, May 14, 2023 at 12:45:22 PM UTC-5, luke.l...@gmail.com wrote:
>> On Tuesday, November 22, 2022 at 5:36:11 PM UTC, MitchAlsup wrote:
>>
>>> Something the readers should be aware of:: Saturation makes the
>>> arithmetic slower (by about 2 gates) because adders are set up to
>>> wrap. Saturation requires the detection of wrap (easy enough) and
>>> then the output of the adder basically has to go through a 3-way
>>> multiplexer that chooses from {lbound, result, ubound}. So, you may
>>> have just made your frequency lower by 5%-6%.
> <
>> what about passing that to the next stage (after the add,
>> just before write-to-regfile)? a post-analysis was what i
>> was planning in the implementation of SVP64: pass enough
>> from an *unmodified* pipeline to an augmented CCode step.
> <
> If you pass the saturation off until the cycle after addition, you cannot
> use the result in the subsequent cycle--but only in the subsequent
> subsequent cycle (latency = 2).

I reckon that most uses of saturating arithmetic is in data processing,
where latency is not as much of an issue (there are usually plenty of
other parallelization opportunities - e.g. multiple concurrent data
chains).

In my implementation I have assumed that saturating arithmetic incur an
extra cycle of latency.

>>
>> given that Power ISA already has CCs (EQ,LT,GT) and Carry-in
>> and Carry-out i am not feeling it to be unreasonable.
>>
>> l.