Josh Vanderhoof wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>
>> MitchAlsup wrote:
>>> On Sunday, May 9, 2021 at 1:45:06 PM UTC-5, Stefan Monnier wrote:
>>>> Stefan Monnier [2021-05-09 14:35:28] wrote:
>>>>>> Yes that makes sense. Specifically for FP8, the increased dynamic range
>>>>>> is by far the most important trait. I've even seen examples of using
>>>>>> 1:5:2 in DNN:s (deep neural networks) where dynamic range is often more
>>>>>> important than precision.
>>>>> Indeed 1:5:2 is arguably more useful than 1:4:3.
>>>> An alternative of course is to use a log-base representation. So your
>>>> 8bit data is split 1:7 between a sign and an exponent, with no mantissa
>>>> at all and then you choose your dynamic range by picking the base.
>>>> Multiplication is easy but addition is takes more effort.
>>> <
>>> Really ?!?!?
>>> Both are implemented with table look ups with concatenated values as the
>>> address.
>>
>> Agreed, in a HW implementation you don't even need a full 64K (8+8
>> bits), since the sign logic can go on in parallel with the table
>> access.
>>
>> I.e. 14-bit tables for each operation is sufficient, so that is about
>> 14 KB x 4 = 56 KB of rom space?
>
> Don't you only need half the table for the commutative ops?
>
Even for FADD/FMUL you need the full table unless you want to start by
sorting the inputs, and you can't do that for FSUB/FDIV so the savings
are relatively small.

Terje

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

>>> An alternative of course is to use a log-base representation. So your
>>> 8bit data is split 1:7 between a sign and an exponent, with no mantissa
>>> at all and then you choose your dynamic range by picking the base.
>>> Multiplication is easy but addition is takes more effort.
>> <
>> Really ?!?!?
>> Both are implemented with table look ups with concatenated values as the
>> address.
>
> Agreed, in a HW implementation you don't even need a full 64K (8+8 bits),
> since the sign logic can go on in parallel with the table access.
>
> I.e. 14-bit tables for each operation is sufficient, so that is about 14 KB
> x 4 = 56 KB of rom space?

For FMUL and FDIV, a logarithm based representation means that these
operations are implemented as addition/substraction of the exponent,
which I don't think deserves to be implemented via table lookup.

So we're only really talking about 2 operations (FADD and FSUB) which
reduce to a single operation after fiddling with the sign.

I'm sill not sure if a 32kB table is the best choice for FADD, tho since
with the low-precision of FP8, I'd expect that of the 32k different
possible cases, the overwhelming majority of cases fall into the
situation where x + y ≃ max(x, y) because the smaller of the two is
smaller than the relative error of the larger (and I think we can find
those cases cheaply by subtracting the two exponents and checking if
it's magnitude is larger than the threshold).

Stefan

On Tuesday, May 11, 2021 at 3:14:10 AM UTC-5, Terje Mathisen wrote:
> Ivan Godard wrote:
> > On 5/10/2021 2:11 PM, MitchAlsup wrote:
> >> On Monday, May 10, 2021 at 3:53:45 PM UTC-5, robf...@gmail.com wrote:
> >>> ANY1 supports a 21 bit branch displacement for branching +/-1MB. It
> >>> may also store the return address in the target register allowing
> >>> conditional branch to subroutine.
> >> <
> >> How often do you find conditional branching to a subroutine to be
> >> effective ?
> >
> > Very frequent in Mill code, due to predication of calls when EBBs are
> > folded together to let both then and else run interleaved. Probably rare
> > otherwise. Consequently asking "how often do you see?" is not very
> > informative unless also asking whether the compiler takes advantage of
> > the conditional.
> A conditional function call would be very useful whenever you write any
> code that process a stream of data, using a local buffer which you have
> to refill whenever you reach the low-water mark.
>
> I.e.
>
> if (amount < low_limit) fill_buffer()
>
> This happens a lot in most stream/file library code, as well as wjen
> processing bitstreams for a codec.
<
But does the code not look more like::

if( buf->amount < low_limit ) buf->fill_pointer = fill_buffer( buf->file, buf->fill_pointer );
<
>
> Terje
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

On 2021-05-10, MitchAlsup wrote:
> On Monday, May 10, 2021 at 3:53:45 PM UTC-5, robf...@gmail.com wrote:
>> ANY1 supports a 21 bit branch displacement for branching +/-1MB. It may also store the return address in the target register allowing conditional branch to subroutine.
> <
> How often do you find conditional branching to a subroutine to be effective ?

I had conditional branch-and-link in my ISA at one point (probably
inspired by POWER or some such ISA), but then I realized that it
actually implied a conditional move to the link register, which
was something I wanted to avoid (plus the instructions ate up valuable
instruction encoding space) - so I removed those instructions.

>
> {I remember using this a lot in 8085 assembly coding, but when writing in C I seldom find
> it profitable because all the arguments had to be in the proper registers before the condition
> to use the conditionality of the call.
>
> Also, do you have a conditional return, or does the epilogue of the subroutine "get in the way" ??
> <
>> Operation for BEQ:
>> Rt = IP + 8
>> If (Ra = Rb)
>> If (Rc = 63)
>> IP = IP + Displacement
>> Else
>> IP = Rc + Displacement
>>
>> There really needs to be only a small number of return address registers. So in a couple of designs I have trimmed the target register down to two bits allowing three return address registers, and then extended the constant field of the JAL instruction by three extra bits. It makes quite a difference being able to branch +-16MB for instance instead of 2MB. 2MB is not enough for some code.
> <
> I got ±128MB from my ISA.
>

On 5/11/2021 12:27 PM, Marcus wrote:
> On 2021-05-10, MitchAlsup wrote:
>> On Monday, May 10, 2021 at 3:53:45 PM UTC-5, robf...@gmail.com wrote:
>>> ANY1 supports a 21 bit branch displacement for branching +/-1MB. It
>>> may also store the return address in the target register allowing
>>> conditional branch to subroutine.
>> <
>> How often do you find conditional branching to a subroutine to be
>> effective ?
>
> I had conditional branch-and-link in my ISA at one point (probably
> inspired by POWER or some such ISA), but then I realized that it
> actually implied a conditional move to the link register, which
> was something I wanted to avoid (plus the instructions ate up valuable
> instruction encoding space) - so I removed those instructions.
>

It exists indirectly in BJX2 as a result of predicated instructions, and
the ability to predicate branches.
BSR?T / BSR?F

It sort of exists in a gray area...
Neither allowed nor prohibited, will probably work with the FPGA
implementation.

>>
>> {I remember using this a lot in 8085 assembly coding, but when writing
>> in C I seldom find
>> it profitable because all the arguments had to be in the proper
>> registers before the condition
>> to use the conditionality of the call.
>>
>> Also, do you have a conditional return, or does the epilogue of the
>> subroutine "get in the way" ??
>> <
>>> Operation for BEQ:
>>> Rt = IP + 8
>>> If (Ra = Rb)
>>> If (Rc = 63)
>>> IP = IP + Displacement
>>> Else
>>> IP = Rc + Displacement
>>>
>>> There really needs to be only a small number of return address
>>> registers. So in a couple of designs I have trimmed the target
>>> register down to two bits allowing three return address registers,
>>> and then extended the constant field of the JAL instruction by three
>>> extra bits. It makes quite a difference being able to branch +-16MB
>>> for instance instead of 2MB. 2MB is not enough for some code.
>> <
>> I got ±128MB from my ISA.
>>
>

At the moment, I now have, by instruction size:
16-bit: ± 256B (Disp8s)
32-bit: ± 1MB (Disp20s)
64-bit: ± 8GB (Disp33s, *)
~ 256TB (Abs48)

*: After realizing a new trick that allowed me to effectively eliminate
the modular addressing issue from branches while actually reducing cost
and latency in a few areas (and sidesteps the need for a separate LEA,
which has now also been expanded to ± 32GB with LEA.Q).

Though, the latter change was basically "just make it a little wider"
(adding a few bits to the AGU width didn't hurt things too badly). Also
it allows using both "signed int" and "unsigned int" as displacements
provided they are properly extended. Using "long" or "long long" as an
array index would still require explicit ALU ops.

Hopefully, displacements shouldn't be too much of an issue anymore in
this case.

On Tuesday, May 11, 2021 at 2:31:30 PM UTC-5, BGB wrote:
> On 5/11/2021 12:27 PM, Marcus wrote:
> > On 2021-05-10, MitchAlsup wrote:
> >> On Monday, May 10, 2021 at 3:53:45 PM UTC-5, robf...@gmail.com wrote:
> >>> ANY1 supports a 21 bit branch displacement for branching +/-1MB. It
> >>> may also store the return address in the target register allowing
> >>> conditional branch to subroutine.
> >> <
> >> How often do you find conditional branching to a subroutine to be
> >> effective ?
> >
> > I had conditional branch-and-link in my ISA at one point (probably
> > inspired by POWER or some such ISA), but then I realized that it
> > actually implied a conditional move to the link register, which
> > was something I wanted to avoid (plus the instructions ate up valuable
> > instruction encoding space) - so I removed those instructions.
> >
> It exists indirectly in BJX2 as a result of predicated instructions, and
> the ability to predicate branches.
> BSR?T / BSR?F
>
> It sort of exists in a gray area...
> Neither allowed nor prohibited, will probably work with the FPGA
> implementation.
> >>
> >> {I remember using this a lot in 8085 assembly coding, but when writing
> >> in C I seldom find
> >> it profitable because all the arguments had to be in the proper
> >> registers before the condition
> >> to use the conditionality of the call.
> >>
> >> Also, do you have a conditional return, or does the epilogue of the
> >> subroutine "get in the way" ??
> >> <
> >>> Operation for BEQ:
> >>> Rt = IP + 8
> >>> If (Ra = Rb)
> >>> If (Rc = 63)
> >>> IP = IP + Displacement
> >>> Else
> >>> IP = Rc + Displacement
> >>>
> >>> There really needs to be only a small number of return address
> >>> registers. So in a couple of designs I have trimmed the target
> >>> register down to two bits allowing three return address registers,
> >>> and then extended the constant field of the JAL instruction by three
> >>> extra bits. It makes quite a difference being able to branch +-16MB
> >>> for instance instead of 2MB. 2MB is not enough for some code.
> >> <
> >> I got ±128MB from my ISA.
> >>
> >
> At the moment, I now have, by instruction size:
> 16-bit: ± 256B (Disp8s)
> 32-bit: ± 1MB (Disp20s)
> 64-bit: ± 8GB (Disp33s, *)
> ~ 256TB (Abs48)
>
It appears you like the <alt>0177</alt> sequence.......
>
> *: After realizing a new trick that allowed me to effectively eliminate
> the modular addressing issue from branches while actually reducing cost
> and latency in a few areas (and sidesteps the need for a separate LEA,
> which has now also been expanded to ± 32GB with LEA.Q).
>
> Though, the latter change was basically "just make it a little wider"
> (adding a few bits to the AGU width didn't hurt things too badly). Also
> it allows using both "signed int" and "unsigned int" as displacements
> provided they are properly extended. Using "long" or "long long" as an
> array index would still require explicit ALU ops.
>
>
> Hopefully, displacements shouldn't be too much of an issue anymore in
> this case.

On 5/11/2021 2:43 PM, MitchAlsup wrote:
> On Tuesday, May 11, 2021 at 2:31:30 PM UTC-5, BGB wrote:
>> On 5/11/2021 12:27 PM, Marcus wrote:
>>> On 2021-05-10, MitchAlsup wrote:
>>>> On Monday, May 10, 2021 at 3:53:45 PM UTC-5, robf...@gmail.com wrote:
>>>>> ANY1 supports a 21 bit branch displacement for branching +/-1MB. It
>>>>> may also store the return address in the target register allowing
>>>>> conditional branch to subroutine.
>>>> <
>>>> How often do you find conditional branching to a subroutine to be
>>>> effective ?
>>>
>>> I had conditional branch-and-link in my ISA at one point (probably
>>> inspired by POWER or some such ISA), but then I realized that it
>>> actually implied a conditional move to the link register, which
>>> was something I wanted to avoid (plus the instructions ate up valuable
>>> instruction encoding space) - so I removed those instructions.
>>>
>> It exists indirectly in BJX2 as a result of predicated instructions, and
>> the ability to predicate branches.
>> BSR?T / BSR?F
>>
>> It sort of exists in a gray area...
>> Neither allowed nor prohibited, will probably work with the FPGA
>> implementation.
>>>>
>>>> {I remember using this a lot in 8085 assembly coding, but when writing
>>>> in C I seldom find
>>>> it profitable because all the arguments had to be in the proper
>>>> registers before the condition
>>>> to use the conditionality of the call.
>>>>
>>>> Also, do you have a conditional return, or does the epilogue of the
>>>> subroutine "get in the way" ??
>>>> <
>>>>> Operation for BEQ:
>>>>> Rt = IP + 8
>>>>> If (Ra = Rb)
>>>>> If (Rc = 63)
>>>>> IP = IP + Displacement
>>>>> Else
>>>>> IP = Rc + Displacement
>>>>>
>>>>> There really needs to be only a small number of return address
>>>>> registers. So in a couple of designs I have trimmed the target
>>>>> register down to two bits allowing three return address registers,
>>>>> and then extended the constant field of the JAL instruction by three
>>>>> extra bits. It makes quite a difference being able to branch +-16MB
>>>>> for instance instead of 2MB. 2MB is not enough for some code.
>>>> <
>>>> I got ±128MB from my ISA.
>>>>
>>>
>> At the moment, I now have, by instruction size:
>> 16-bit: ± 256B (Disp8s)
>> 32-bit: ± 1MB (Disp20s)
>> 64-bit: ± 8GB (Disp33s, *)
>> ~ 256TB (Abs48)
>>
> It appears you like the <alt>0177</alt> sequence.......

I figured since it was brought up, maybe you were getting annoyed with
me typing +/- or something...

Otherwise, sometimes wishes that usenet/pastebin/... were properly
whitespace preserving.

Also wishes that more stuff did "proper" monospace fonts...
Like, even when one specifies a monospace font, a lot of programs still
don't give "proper" monospace display.

....

>>
>> *: After realizing a new trick that allowed me to effectively eliminate
>> the modular addressing issue from branches while actually reducing cost
>> and latency in a few areas (and sidesteps the need for a separate LEA,
>> which has now also been expanded to ± 32GB with LEA.Q).
>>
>> Though, the latter change was basically "just make it a little wider"
>> (adding a few bits to the AGU width didn't hurt things too badly). Also
>> it allows using both "signed int" and "unsigned int" as displacements
>> provided they are properly extended. Using "long" or "long long" as an
>> array index would still require explicit ALU ops.
>>
>>
>> Hopefully, displacements shouldn't be too much of an issue anymore in
>> this case.

On 5/11/2021 10:27 AM, Marcus wrote:
> On 2021-05-10, MitchAlsup wrote:
>> On Monday, May 10, 2021 at 3:53:45 PM UTC-5, robf...@gmail.com wrote:
>>> ANY1 supports a 21 bit branch displacement for branching +/-1MB. It
>>> may also store the return address in the target register allowing
>>> conditional branch to subroutine.
>> <
>> How often do you find conditional branching to a subroutine to be
>> effective ?
>
> I had conditional branch-and-link in my ISA at one point (probably
> inspired by POWER or some such ISA), but then I realized that it
> actually implied a conditional move to the link register, which
> was something I wanted to avoid (plus the instructions ate up valuable
> instruction encoding space) - so I removed those instructions.

Doesn't have to require conditional move.

In a belt machine, a call must update the belt in the same way whether
taken or not, so Mill conditional calls drop null results if the call is
untaken. Because of the availability of NaR as a metadata marker for
invalid/missing data, the nulls are NaRs and so will poison any
subsequent actual use of the value, but that's a QOI feature independent
of the conditional call feature.

In your case, you could have the link register unconditionally
klobbered, either by the return address if taken, or a null if untaken.
Or, if the return address can be meaningfully used whether taken or not,
set the register unconditionally to what would be the return address if
it had been taken. An untaken conditional call need not be totally free
of side effects; it just must not enter the called address.

Stefan Monnier wrote:
>>>> An alternative of course is to use a log-base representation. So your
>>>> 8bit data is split 1:7 between a sign and an exponent, with no mantissa
>>>> at all and then you choose your dynamic range by picking the base.
>>>> Multiplication is easy but addition is takes more effort.
>>> <
>>> Really ?!?!?
>>> Both are implemented with table look ups with concatenated values as the
>>> address.
>>
>> Agreed, in a HW implementation you don't even need a full 64K (8+8 bits),
>> since the sign logic can go on in parallel with the table access.
>>
>> I.e. 14-bit tables for each operation is sufficient, so that is about 14 KB
>> x 4 = 56 KB of rom space?
>
> For FMUL and FDIV, a logarithm based representation means that these
> operations are implemented as addition/substraction of the exponent,
> which I don't think deserves to be implemented via table lookup.

OK, for a pure log with no mantissa (or an implied mantissa of 1), I
agree that FDIV/FMUL deserves to be implemented as integer sub/add. :-)

You do need to detect zero inputs and handle that separately.
>
> So we're only really talking about 2 operations (FADD and FSUB) which
> reduce to a single operation after fiddling with the sign.

I did assume that the actual sign bit fiddling had finished, so that
FSUB is two terms with opposite sign, and FADD means equal sign.

Assuming default rounding and FADD, the larger value wins unless the
smaller is equal or exactly 1 below, in which case we'll round up.

With ceil() logic the smaller value plays the role of the sticky bit, so
any non-zero value can modify (i.e. increment) the result, while floor()
is truncate unless both inputs are equal.

For FSUB the logic is similar but opposite, so I do agree that a logic
table based on a single comparison of the two inputs and the rounding
mode is sufficient: No need for any tables at all. :-)
>
> I'm sill not sure if a 32kB table is the best choice for FADD, tho since
> with the low-precision of FP8, I'd expect that of the 32k different
> possible cases, the overwhelming majority of cases fall into the
> situation where x + y ≃ max(x, y) because the smaller of the two is
> smaller than the relative error of the larger (and I think we can find
> those cases cheaply by subtracting the two exponents and checking if
> it's magnitude is larger than the threshold).

Yeah, it is only when you have at least two manitssa bits (one of them
hidden) that you need more complicated logic and a lookup table becomes
viable.

Terje

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

MitchAlsup wrote:
> On Tuesday, May 11, 2021 at 3:14:10 AM UTC-5, Terje Mathisen wrote:
>> Ivan Godard wrote:
>>> On 5/10/2021 2:11 PM, MitchAlsup wrote:
>>>> On Monday, May 10, 2021 at 3:53:45 PM UTC-5, robf...@gmail.com wrote:
>>>>> ANY1 supports a 21 bit branch displacement for branching +/-1MB. It
>>>>> may also store the return address in the target register allowing
>>>>> conditional branch to subroutine.
>>>> <
>>>> How often do you find conditional branching to a subroutine to be
>>>> effective ?
>>>
>>> Very frequent in Mill code, due to predication of calls when EBBs are
>>> folded together to let both then and else run interleaved. Probably rare
>>> otherwise. Consequently asking "how often do you see?" is not very
>>> informative unless also asking whether the compiler takes advantage of
>>> the conditional.
>> A conditional function call would be very useful whenever you write any
>> code that process a stream of data, using a local buffer which you have
>> to refill whenever you reach the low-water mark.
>>
>> I.e.
>>
>> if (amount < low_limit) fill_buffer()
>>
>> This happens a lot in most stream/file library code, as well as wjen
>> processing bitstreams for a codec.
> <
> But does the code not look more like::
>
> if( buf->amount < low_limit ) buf->fill_pointer = fill_buffer( buf->file, buf->fill_pointer );

Not really, when I've written code where these details matter, I am
typically writing asm, and the entire context is already implied, i.e.
in fixed register positions.

It has more in common with a sw trap to fixup a COW page access, i.e.
the function is normally very seldom called, but when it happens, it has
to either know up front or figure out on the fly what the environment is
and what to do.

On either My 66000 or Mill function calls are so cheap that inlining of
even small functions is less interesting: Saving code space becomes
relatively more important.

Terje

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

Terje Mathisen <terje.mathisen@tmsw.no> schrieb:

> OK, for a pure log with no mantissa (or an implied mantissa of 1), I
> agree that FDIV/FMUL deserves to be implemented as integer sub/add. :-)
>
> You do need to detect zero inputs and handle that separately.

Unless you handle zero as a special number, which might make sense.

Thomas Koenig wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
>
>> OK, for a pure log with no mantissa (or an implied mantissa of 1), I
>> agree that FDIV/FMUL deserves to be implemented as integer sub/add. :-)
>>
>> You do need to detect zero inputs and handle that separately.
>
> Unless you handle zero as a special number, which might make sense.
>
That's actually what I do in my sw emulation, i.e. zero/inf/nan are all
special and handled in parallel with the normal inputs which can then
assume that all inputs are sane.

Terje

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

> Assuming default rounding and FADD, the larger value wins unless the smaller
> is equal or exactly 1 below, in which case we'll round up.

I think this is only true if the base of your logarithm is something
like 2 (which I expect wouldn't be the most common choice, it
corresponds to a "standard" FP but with 0 mantissa bits).

E.g. I think the moral equivalent of 2 mantissa bits would be to use
a logarithm of base of 2^¼. When the logarithm's base is closer to
1 (as in this example), then you have to consider more cases.

Stefan

John Levine <johnl@taugh.com> writes:
>According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
>>>On small systems, I suppose. Floating point was standard or at least a
>>>widely provided option on large computers by the early 1960s.
>>
>>But it still was much slower than integer arithmetic on most machines.
>
>I happen to have a 360/67 manual here. It and the similar /65 were
>workhorse mainframes in the early 1970s.
>
>Memory to register integer add took 1.4us, floating took 2.43 short, 2.45 double
>Integer multiply was 4.8us, 4.4 short (faster than integer), 7.6 double
>Integer divide was 8.7us, float 7.3, double 14.10

Not bad.

>I have manuals for the 386 and 486, where float arithmetic was also
>about half the speed of fixed, even though integer arithmetic was
>32x32 and float was all extended with 64 fraction bits. Doesn't seem
>much slower to me.

According to
<https://www2.math.uni-wuppertal.de/~fpf/Uebungen/GdR-SS02/opcode_f.html>,
8087-Pentium take the following number of cycles for FADD(P) and FMUL(P):

variations/
operand 8087 287 387 486 Pentium
fadd 70-100 70-100 23-34 8-20 3/1 FX
fadd mem32 90-120+EA 90-120 24-32 8-20 3/1 FX
fadd mem64 95-125+EA 95-125 29-37 8-20 3/1 FX
faddp 75-105 75-105 23-31 8-20 3/1 FX
fmul reg s 90-105 90-105 29-52 16 3/1 FX
fmul reg 130-145 130-145 46-57 16 3/1 FX
fmul mem32 (110-125)+EA 110-125 27-35 11 3/1 FX
fmul mem64 (154-168)+EA 154-168 32-57 14 3/1 FX
fmulp reg s 94-108 94-108 29-52 16 3/1 FX
fmulp reg 134-148 134-148 29-57 16 3/1 FX

and for comparison ADD and MUL:

add operands bytes 8088 186 286 386 486 Pentium
add reg, reg 2 3 3 2 2 1 1 UV
add mem, reg 2+d(0,2) 24+EA 10 7 7 3 3 UV
add reg, mem 2+d(0,2) 13+EA 10 7 6 2 2 UV
mul r32 2 - - - 9-38 13-42 10 NP
mul mem32 2+d(0-2) - - - 12-41 13-42 10 NP

So on the 486 "add reg, reg" is 8-20 times faster than "faddp", but
fmul is as fast or faster than mul (and imul has the same cycle counts
as mul). On the Pentium FMUL is >3 times as fast as MUL, and
pipelined (i.e., 1 fmul/cycle can be started, and I don't think that
MUL/IMUL can).

>If you can write your code using the same number of fixed instructions
>as floats, sure, it'll be faster, but if you need to add extra code to
>explicit scaling, I doubt it'll really be faster.

If the code does many adds, fixed point will be faster (no scaling
needed if all the summands and the result have the same scale), if it
does primarily muls, floating will be faster even on the 386, 486, and
Pentium, because MUL is slow, and because scaling is needed (but
scaling is ideally a shift).

>On the other hand, if you had a 286 or 386 with no 287 or 387 and
>were simulating floating point in software, *that* was slow.

On the 8087 and 287, floating point is also slow; but given the cost
of synthesized 32x32-bit multiplication on the 8086 and 80286 you
again have the same balance as above.

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

On 2021-05-11, Ivan Godard wrote:
> On 5/11/2021 10:27 AM, Marcus wrote:
>> On 2021-05-10, MitchAlsup wrote:
>>> On Monday, May 10, 2021 at 3:53:45 PM UTC-5, robf...@gmail.com wrote:
>>>> ANY1 supports a 21 bit branch displacement for branching +/-1MB. It
>>>> may also store the return address in the target register allowing
>>>> conditional branch to subroutine.
>>> <
>>> How often do you find conditional branching to a subroutine to be
>>> effective ?
>>
>> I had conditional branch-and-link in my ISA at one point (probably
>> inspired by POWER or some such ISA), but then I realized that it
>> actually implied a conditional move to the link register, which
>> was something I wanted to avoid (plus the instructions ate up valuable
>> instruction encoding space) - so I removed those instructions.
>
> Doesn't have to require conditional move.
>
> In a belt machine, a call must update the belt in the same way whether
> taken or not, so Mill conditional calls drop null results if the call is
> untaken. Because of the availability of NaR as a metadata marker for
> invalid/missing data, the nulls are NaRs and so will poison any
> subsequent actual use of the value, but that's a QOI feature independent
> of the conditional call feature.
>
> In your case, you could have the link register unconditionally
> klobbered, either by the return address if taken, or a null if untaken.
> Or, if the return address can be meaningfully used whether taken or not,
> set the register unconditionally to what would be the return address if
> it had been taken. An untaken conditional call need not be totally free
> of side effects; it just must not enter the called address.

True, I did not think of that at the time. Today I don't think I'll
reintroduce those instructions since I'd have to rearrange instruction
encoding etc (and I think the ISA is in a pretty good place right now),
and honestly I don't know how much of an impact conditional
branch-and-link would have for my ISA.

/Marcus

On 5/10/2021 11:49 AM, Ivan Godard wrote:
> On 5/10/2021 9:22 AM, MitchAlsup wrote:
>> On Sunday, May 9, 2021 at 10:22:49 PM UTC-5, BGB wrote:
>>> On 5/9/2021 4:28 AM, Thomas Koenig wrote:
>>>> BGB <cr8...@gmail.com> schrieb:
>>>>
>>>>> IMUL (Lane 1)
>>>>> 32*32 -> 64
>>>>
>>>> Do you have two instructions (one for signed and one for unsigned)
>>>> or three (one for the lower half, one for signed high, one for
>>>> unsigned high)? The latter version could save you some ALU
>>>> complexity and some latency in the (probably common) case where
>>>> only a 32*32 multiplication is needed, at the cost of added
>>>> instructions for the 32*32-> 64 bit case.
>>>>
>>> There are actually more cases:
>>> MULS: 32*32->32, Result is sign-extended from low 32 bits
>> IMUL
>>> MULU: 32*32->32, Result is zero-extended from low 32 bits
>> UMUL
>>> DMULS: 32*32->64, 64-bit signed result
>> CARRY; IMUL
>>> DMULU: 32*32->64, 64-bit unsigned result
>> CARRY; UMUL
>>>
>>> The former give the typical behaviors one expects in C, the latter gives
>>> the widened results.
>>>
>>> These exist as 3R forms, so:
>>> DMULU R4, R5, R7 // R7 = R4 * R5
>> <
>> All mine are 2-operand 1-result
>>>
>>>
>>> Originally, there were also multiply ops which multiplied two inputs and
>>> then stored a pair of results in R0 and R1, more like the original
>>> SuperH multiply ops, but I dropped these for various reasons.
>> <
>> Consumes way more OpCode space that in useful
>>>
>>> There are cases where DMACS or DMACU instructions could be useful:
>>> DMACU R4, R5, R7 // R7 = R4 * R5 + R7
>> <
>> IMAC and UMAC
>>>
>>> But, I don't currently have these.
>>>
>>>
>>> Eg (64-bit signed multiply):
>>> SHADQ R4, -32, R6 | SHADQ R5, -32, R7 //1c
>>> DMULS R4, R7, R16 //1c
>>> DMACS R5, R6, R16 //3c (2c penalty)
>>> SHADQ R16, 32, R2 //3c (2c penalty)
>>> DMACU R4, R5, R2 //1c
>>> RTS
>>>
>>> Though, while fewer instructions than the current form, the above
>>> construction would still be pretty bad in terms of interlock penalties.
>>>
>>> SHADQ R4, -32, R6 | SHADQ R5, -32, R7 //1c
>>> DMULS R5, R6, R16 //1c
>>> DMULS R4, R7, R17 //1c
>>> DMULU R4, R5, R18 //1c
>>> ADD R16, R17, R19 //2c (1c penalty, DMULS R17)
>>> SHADQ R19, 32, R2 //2c (1c penalty, ADD R19)
>>> ADD R18, R2 //1c
>>> RTS
>>>
>>> Both cases would have approximately the same clock-cycle count (assuming
>>> both cases have a 3-cycle latency).
>> <
>> Which is why I used CARRY; xMUL
>>>
>>> ( Where recently, I have gotten around to modifying things such that the
>>> multiplier is now fully pipelined... )
>>>
>>>
>>>
>>> Otherwise, my time recently has mostly been being consumed by
>>> debugging...
>> <
>> Sherlock we know you well...........
>>>
>>> Then tries and seeing if I can get stuff to pass timing at 75MHz again
>>> (hopefully without wrecking stuff quite as bad this time). This
>>> sub-effort also revealed a few bugs (*), though there are still some
>>> bugs I have yet to resolve...
>>>
>>> *: Eg, after boosting the core to 75MHz while leaving the MMIO bus at
>>> 50MHz, stuff was breaking in simulation due to the L2 Ringbus <->
>>> MMIO-Bus bridge not waiting for the MMIO-Bus to return to a READY state
>>> before returning back to an idle state.
>>>
>>> It was then possible for the response to travel the rings and get back
>>> to the L1, which then allows execution to continue, with the CPU core
>>> then issuing another MMIO request, which then travels along the rings
>>> back to the MMIO bridge, in less time than it took for the 'OK -> READY'
>>> transition to happen on the MMIO bus...
>>>
>>> The way the bridge was designed, it would then try to initiate a
>>> request, see that the MMIO-Bus state was 'OK', and use whatever result
>>> was present (losing the request or returning garbage).
>>>
>>> This may have been happening at 50MHz as well, and could have possibly
>>> been leading to some of the bugs I had seen.
>>>
>>>
>>> Or such...
>
> Do you have any saturating multiplies? Why or why not?

For BJX2?
Not currently.

There are neither saturating multiplies nor saturated ADD/SUB.

Granted, these could be useful for Fixed-point SIMD, but I was mostly
being careful with value ranges and arithmetic to limit the likelihood
of overflow/underflow.

As for why not:
These add a bit of cost and complexity.

Say, one goes from needing ops for, say:
PADD.W, PMULU.W, PMULS.W, ...
To:
PADDS.W, PADDU.W, PADDSS.W, PADDUS.W,
PMULS.W, PMULU.W, PMULSS.W, PMULUS.W
...

For vector cases, it is usually possible to keep a certain amount of a
"safety zone" at the top and bottom of the range such that overflow is
unlikely, and writing calculations such that they are more likely to
undershoot than overshoot, ...

There are some "packed-compare" and "packed-select" ops which can also
help here.

For non-SIMD cases, clamping can be done like:
CMPGT R4, 0
MOV?T 0, R4
CMPGT R4, 255
MOV?F 255, R4

I had at one point considered specialized range-clamping ops, like:
CLAMPU.B R4, R4 //clamp to Unsigned Byte range
CLAMPS.S R4, R4 //clamp to Signed Short range

But, never added them...

Mostly it is an issue of not being common enough (or expensive enough in
the naive case) to justify the added cost.

On Wednesday, May 12, 2021 at 2:17:33 PM UTC-5, BGB wrote:
> On 5/10/2021 11:49 AM, Ivan Godard wrote:
> > On 5/10/2021 9:22 AM, MitchAlsup wrote:
> >> On Sunday, May 9, 2021 at 10:22:49 PM UTC-5, BGB wrote:
> >>> On 5/9/2021 4:28 AM, Thomas Koenig wrote:
> >>>> BGB <cr8...@gmail.com> schrieb:
> >>>>
> >>>>> IMUL (Lane 1)
> >>>>> 32*32 -> 64
> >>>>
> >>>> Do you have two instructions (one for signed and one for unsigned)
> >>>> or three (one for the lower half, one for signed high, one for
> >>>> unsigned high)? The latter version could save you some ALU
> >>>> complexity and some latency in the (probably common) case where
> >>>> only a 32*32 multiplication is needed, at the cost of added
> >>>> instructions for the 32*32-> 64 bit case.
> >>>>
> >>> There are actually more cases:
> >>> MULS: 32*32->32, Result is sign-extended from low 32 bits
> >> IMUL
> >>> MULU: 32*32->32, Result is zero-extended from low 32 bits
> >> UMUL
> >>> DMULS: 32*32->64, 64-bit signed result
> >> CARRY; IMUL
> >>> DMULU: 32*32->64, 64-bit unsigned result
> >> CARRY; UMUL
> >>>
> >>> The former give the typical behaviors one expects in C, the latter gives
> >>> the widened results.
> >>>
> >>> These exist as 3R forms, so:
> >>> DMULU R4, R5, R7 // R7 = R4 * R5
> >> <
> >> All mine are 2-operand 1-result
> >>>
> >>>
> >>> Originally, there were also multiply ops which multiplied two inputs and
> >>> then stored a pair of results in R0 and R1, more like the original
> >>> SuperH multiply ops, but I dropped these for various reasons.
> >> <
> >> Consumes way more OpCode space that in useful
> >>>
> >>> There are cases where DMACS or DMACU instructions could be useful:
> >>> DMACU R4, R5, R7 // R7 = R4 * R5 + R7
> >> <
> >> IMAC and UMAC
> >>>
> >>> But, I don't currently have these.
> >>>
> >>>
> >>> Eg (64-bit signed multiply):
> >>> SHADQ R4, -32, R6 | SHADQ R5, -32, R7 //1c
> >>> DMULS R4, R7, R16 //1c
> >>> DMACS R5, R6, R16 //3c (2c penalty)
> >>> SHADQ R16, 32, R2 //3c (2c penalty)
> >>> DMACU R4, R5, R2 //1c
> >>> RTS
> >>>
> >>> Though, while fewer instructions than the current form, the above
> >>> construction would still be pretty bad in terms of interlock penalties.
> >>>
> >>> SHADQ R4, -32, R6 | SHADQ R5, -32, R7 //1c
> >>> DMULS R5, R6, R16 //1c
> >>> DMULS R4, R7, R17 //1c
> >>> DMULU R4, R5, R18 //1c
> >>> ADD R16, R17, R19 //2c (1c penalty, DMULS R17)
> >>> SHADQ R19, 32, R2 //2c (1c penalty, ADD R19)
> >>> ADD R18, R2 //1c
> >>> RTS
> >>>
> >>> Both cases would have approximately the same clock-cycle count (assuming
> >>> both cases have a 3-cycle latency).
> >> <
> >> Which is why I used CARRY; xMUL
> >>>
> >>> ( Where recently, I have gotten around to modifying things such that the
> >>> multiplier is now fully pipelined... )
> >>>
> >>>
> >>>
> >>> Otherwise, my time recently has mostly been being consumed by
> >>> debugging...
> >> <
> >> Sherlock we know you well...........
> >>>
> >>> Then tries and seeing if I can get stuff to pass timing at 75MHz again
> >>> (hopefully without wrecking stuff quite as bad this time). This
> >>> sub-effort also revealed a few bugs (*), though there are still some
> >>> bugs I have yet to resolve...
> >>>
> >>> *: Eg, after boosting the core to 75MHz while leaving the MMIO bus at
> >>> 50MHz, stuff was breaking in simulation due to the L2 Ringbus <->
> >>> MMIO-Bus bridge not waiting for the MMIO-Bus to return to a READY state
> >>> before returning back to an idle state.
> >>>
> >>> It was then possible for the response to travel the rings and get back
> >>> to the L1, which then allows execution to continue, with the CPU core
> >>> then issuing another MMIO request, which then travels along the rings
> >>> back to the MMIO bridge, in less time than it took for the 'OK -> READY'
> >>> transition to happen on the MMIO bus...
> >>>
> >>> The way the bridge was designed, it would then try to initiate a
> >>> request, see that the MMIO-Bus state was 'OK', and use whatever result
> >>> was present (losing the request or returning garbage).
> >>>
> >>> This may have been happening at 50MHz as well, and could have possibly
> >>> been leading to some of the bugs I had seen.
> >>>
> >>>
> >>> Or such...
> >
> > Do you have any saturating multiplies? Why or why not?
>
> For BJX2?
> Not currently.
>
> There are neither saturating multiplies nor saturated ADD/SUB.
>
> Granted, these could be useful for Fixed-point SIMD, but I was mostly
> being careful with value ranges and arithmetic to limit the likelihood
> of overflow/underflow.
>
>
> As for why not:
> These add a bit of cost and complexity.
>
> Say, one goes from needing ops for, say:
> PADD.W, PMULU.W, PMULS.W, ...
> To:
> PADDS.W, PADDU.W, PADDSS.W, PADDUS.W,
> PMULS.W, PMULU.W, PMULSS.W, PMULUS.W
> ...
>
> For vector cases, it is usually possible to keep a certain amount of a
> "safety zone" at the top and bottom of the range such that overflow is
> unlikely, and writing calculations such that they are more likely to
> undershoot than overshoot, ...
>
> There are some "packed-compare" and "packed-select" ops which can also
> help here.
>
>
> For non-SIMD cases, clamping can be done like:
> CMPGT R4, 0
> MOV?T 0, R4
> CMPGT R4, 255
> MOV?F 255, R4
>
> I had at one point considered specialized range-clamping ops, like:
> CLAMPU.B R4, R4 //clamp to Unsigned Byte range
> CLAMPS.S R4, R4 //clamp to Signed Short range
<
<
My 66000 has clamping operations to any bit width--these are a subset
of the extract instructions (which is itself a subset of the shift instruction)
The classical cases are::
SLL R8,R8,<8:0> // unsigned char
SL R8,R8,<8:0> // signed char
<
but there are other cases
<
SLL R8,R9,<11:0> // 11-bit unsigned bit-field
SLL R8,R9,<14:13> // 14-bit field from R9<26:13>
<
These come in signed (sign extended) and unsigned (zero extended) forms.
These add exactly ZERO (nada zilch no} instruction to ISA and are in fact the
basis for the shift instructions with the simple rule of::
width==0 -> width "really =" 64
>
> But, never added them...
<
I never needed to............
>
> Mostly it is an issue of not being common enough (or expensive enough in
> the naive case) to justify the added cost.
<
When you start using LLVM as a front end, it throws these clamps out any time
a value in a register gets arithmetically manipulated--preventing the register from
ever having a value outside of the type defined value-space.
<
Unsigned char i = 0;
........
i++
<
gets compiled to::
<
MOV R19,#0
........
ADD R19,R19,#1
SLL R19,R19,<8:0>
<
Yes it is ugly......but people should not ask for small types unless they need the small type.

On 5/12/2021 12:31 PM, MitchAlsup wrote:

> My 66000 has clamping operations to any bit width--these are a subset
> of the extract instructions (which is itself a subset of the shift instruction)
> The classical cases are::
> SLL R8,R8,<8:0> // unsigned char
> SL R8,R8,<8:0> // signed char
> <
> but there are other cases
> <
> SLL R8,R9,<11:0> // 11-bit unsigned bit-field
> SLL R8,R9,<14:13> // 14-bit field from R9<26:13>
> <
> These come in signed (sign extended) and unsigned (zero extended) forms.
> These add exactly ZERO (nada zilch no} instruction to ISA and are in fact the
> basis for the shift instructions with the simple rule of::
> width==0 -> width "really =" 64

But that calls for full width multiply and then a clamp, which is two
instructions' entropy and the dataflow delay, and doesn't actually clamp
the multiply - consider a signed multiply that overflows (unclamped),
and the low order looks to the clamp as a value of the opposite sign.

Or have I misunderstood?

>>
>> But, never added them...
> <
> I never needed to............
>>
>> Mostly it is an issue of not being common enough (or expensive enough in
>> the naive case) to justify the added cost.
> <
> When you start using LLVM as a front end, it throws these clamps out any time
> a value in a register gets arithmetically manipulated--preventing the register from
> ever having a value outside of the type defined value-space.
> <
> Unsigned char i = 0;
> .......
> i++
> <
> gets compiled to::
> <
> MOV R19,#0
> .......
> ADD R19,R19,#1
> SLL R19,R19,<8:0>
> <
> Yes it is ugly......but people should not ask for small types unless they need the small type.
>

Bit field select, signed and unsigned, is useful, but it's not the same
as saturating arithmetic.

According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
>So on the 486 "add reg, reg" is 8-20 times faster than "faddp", but
>fmul is as fast or faster than mul (and imul has the same cycle counts
>as mul). On the Pentium FMUL is >3 times as fast as MUL, and
>pipelined (i.e., 1 fmul/cycle can be started, and I don't think that
>MUL/IMUL can).

I looked at my 486 manual and that seems right. The 486 float and
integer units ran independently so if you could interleave instuctions
a floating add was only 7 cycles average rather than 10. But it's
still a lot slower than integer if 32 bits is enough. Shifts were 3 or
4 cycles so it didn't take a lot of aligning to tip the balance.

Don't have a Pentium manual handy although I expect bitsavers has one.

It does make the assertion that he rewrote everything in fixed point to
make it faster seem a bit naive.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On Wednesday, May 12, 2021 at 2:53:41 PM UTC-5, Ivan Godard wrote:
> On 5/12/2021 12:31 PM, MitchAlsup wrote:
>
> > My 66000 has clamping operations to any bit width--these are a subset
> > of the extract instructions (which is itself a subset of the shift instruction)
> > The classical cases are::
> > SLL R8,R8,<8:0> // unsigned char
> > SL R8,R8,<8:0> // signed char
> > <
> > but there are other cases
> > <
> > SLL R8,R9,<11:0> // 11-bit unsigned bit-field
> > SLL R8,R9,<14:13> // 14-bit field from R9<26:13>
> > <
> > These come in signed (sign extended) and unsigned (zero extended) forms.
> > These add exactly ZERO (nada zilch no} instruction to ISA and are in fact the
> > basis for the shift instructions with the simple rule of::
> > width==0 -> width "really =" 64
> But that calls for full width multiply and then a clamp, which is two
> instructions' entropy and the dataflow delay, and doesn't actually clamp
> the multiply - consider a signed multiply that overflows (unclamped),
> and the low order looks to the clamp as a value of the opposite sign.
>
> Or have I misunderstood?
<
clamp means to prevent values from being outside of a range
saturate means to prevent a calculation from delivering a value that is out of range.
So::
uint8_t x = (int64_t)y
needs to have the assignment clamped so x has no significance beyond 8-bits.
whereas::
saturated uint8_t x,y,z;
x = y+z;
needs to have the addition saturate.
> >>
> >> But, never added them...
> > <
> > I never needed to............
> >>
> >> Mostly it is an issue of not being common enough (or expensive enough in
> >> the naive case) to justify the added cost.
> > <
> > When you start using LLVM as a front end, it throws these clamps out any time
> > a value in a register gets arithmetically manipulated--preventing the register from
> > ever having a value outside of the type defined value-space.
> > <
> > Unsigned char i = 0;
> > .......
> > i++
> > <
> > gets compiled to::
> > <
> > MOV R19,#0
> > .......
> > ADD R19,R19,#1
> > SLL R19,R19,<8:0>
> > <
> > Yes it is ugly......but people should not ask for small types unless they need the small type.
> >
> Bit field select, signed and unsigned, is useful, but it's not the same
> as saturating arithmetic.
<
Was not implying that is was or is. One has to do with preventing a value container
from containing a value outside of the allotted range, the other has to do with pre-
venting a calculation from delivering a value that is out of range.

On 5/12/2021 2:53 PM, Ivan Godard wrote:
> On 5/12/2021 12:31 PM, MitchAlsup wrote:
>
>> My 66000 has clamping operations to any bit width--these are a subset
>> of the extract instructions (which is itself a subset of the shift
>> instruction)
>> The classical cases are::
>>            SLL        R8,R8,<8:0>           // unsigned char
>>            SL          R8,R8,<8:0>           // signed char
>> <
>> but there are other cases
>> <
>>            SLL        R8,R9,<11:0>         // 11-bit unsigned bit-field
>>            SLL        R8,R9,<14:13>       // 14-bit field from R9<26:13>
>> <
>> These come in signed (sign extended) and unsigned (zero extended) forms.
>> These add exactly ZERO (nada zilch no} instruction to ISA and are in
>> fact the
>> basis for the shift instructions with the simple rule of::
>>   width==0 -> width "really =" 64
>
> But that calls for full width multiply and then a clamp, which is two
> instructions' entropy and the dataflow delay, and doesn't actually clamp
> the multiply - consider a signed multiply that overflows (unclamped),
> and the low order looks to the clamp as a value of the opposite sign.
>
> Or have I misunderstood?
>

Luckily, widening multiply can't overflow...

So, say:
DMULS R4, R5, R2
MOV 2147483647, R6
MOV -2147483648, R7
CMPQGT R6, R2
MOV?T R6, R2
CMPQGT R7, R2
MOV?F R7, R2

But, one doesn't usually clamp each operation, but will rather do a more
complex operation, and then clamp the result.

But, then one is back to making sure that it can't overflow in any
intermediate calculations.

>>>
>>> But, never added them...
>> <
>> I never needed to............
>>>
>>> Mostly it is an issue of not being common enough (or expensive enough in
>>> the naive case) to justify the added cost.
>> <
>> When you start using LLVM as a front end, it throws these clamps out
>> any time
>> a value in a register gets arithmetically manipulated--preventing the
>> register from
>> ever having a value outside of the type defined value-space.
>> <
>> Unsigned char i = 0;
>> .......
>> i++
>> <
>> gets compiled to::
>> <
>>            MOV       R19,#0
>> .......
>>            ADD        R19,R19,#1
>>            SLL         R19,R19,<8:0>
>> <
>> Yes it is ugly......but people should not ask for small types unless
>> they need the small type.
>>
>
> Bit field select, signed and unsigned, is useful, but it's not the same
> as saturating arithmetic.

Yes.
There are built in instructions for sign and zero extension.

But, if (i==255), having i++ wrap to 0 is a very different behavior than
if 'i++' stays at 255.

On 5/12/2021 2:26 PM, BGB wrote:
> On 5/12/2021 2:53 PM, Ivan Godard wrote:
>> On 5/12/2021 12:31 PM, MitchAlsup wrote:
>>
>>> My 66000 has clamping operations to any bit width--these are a subset
>>> of the extract instructions (which is itself a subset of the shift
>>> instruction)
>>> The classical cases are::
>>>            SLL        R8,R8,<8:0>           // unsigned char
>>>            SL          R8,R8,<8:0>           // signed char
>>> <
>>> but there are other cases
>>> <
>>>            SLL        R8,R9,<11:0>         // 11-bit unsigned bit-field
>>>            SLL        R8,R9,<14:13>       // 14-bit field from R9<26:13>
>>> <
>>> These come in signed (sign extended) and unsigned (zero extended) forms.
>>> These add exactly ZERO (nada zilch no} instruction to ISA and are in
>>> fact the
>>> basis for the shift instructions with the simple rule of::
>>>   width==0 -> width "really =" 64
>>
>> But that calls for full width multiply and then a clamp, which is two
>> instructions' entropy and the dataflow delay, and doesn't actually
>> clamp the multiply - consider a signed multiply that overflows
>> (unclamped), and the low order looks to the clamp as a value of the
>> opposite sign.
>>
>> Or have I misunderstood?
>>
>
> Luckily, widening multiply can't overflow...
>
> So, say:
>  DMULS   R4, R5, R2
>  MOV      2147483647, R6
>  MOV     -2147483648, R7
>  CMPQGT  R6, R2
>  MOV?T   R6, R2
>  CMPQGT  R7, R2
>  MOV?F   R7, R2
>
> But, one doesn't usually clamp each operation, but will rather do a more
> complex operation, and then clamp the result.
>
> But, then one is back to making sure that it can't overflow in any
> intermediate calculations.

The problem is that there is always a width for which widening multiply
is not available, but saturating is possible. If you have wXw->d then
you're happy until you need to do dXd->sat(d).

On 5/12/2021 2:27 PM, MitchAlsup wrote:
> On Wednesday, May 12, 2021 at 2:53:41 PM UTC-5, Ivan Godard wrote:
>> On 5/12/2021 12:31 PM, MitchAlsup wrote:
>>
>>> My 66000 has clamping operations to any bit width--these are a subset
>>> of the extract instructions (which is itself a subset of the shift instruction)
>>> The classical cases are::
>>> SLL R8,R8,<8:0> // unsigned char
>>> SL R8,R8,<8:0> // signed char
>>> <
>>> but there are other cases
>>> <
>>> SLL R8,R9,<11:0> // 11-bit unsigned bit-field
>>> SLL R8,R9,<14:13> // 14-bit field from R9<26:13>
>>> <
>>> These come in signed (sign extended) and unsigned (zero extended) forms.
>>> These add exactly ZERO (nada zilch no} instruction to ISA and are in fact the
>>> basis for the shift instructions with the simple rule of::
>>> width==0 -> width "really =" 64
>> But that calls for full width multiply and then a clamp, which is two
>> instructions' entropy and the dataflow delay, and doesn't actually clamp
>> the multiply - consider a signed multiply that overflows (unclamped),
>> and the low order looks to the clamp as a value of the opposite sign.
>>
>> Or have I misunderstood?
> <
> clamp means to prevent values from being outside of a range
> saturate means to prevent a calculation from delivering a value that is out of range.
> So::
> uint8_t x = (int64_t)y
> needs to have the assignment clamped so x has no significance beyond 8-bits.
> whereas::
> saturated uint8_t x,y,z;
> x = y+z;
> needs to have the addition saturate.

True; sorry for sloppy terminology.

>>>>
>>>> But, never added them...
>>> <
>>> I never needed to............
>>>>
>>>> Mostly it is an issue of not being common enough (or expensive enough in
>>>> the naive case) to justify the added cost.
>>> <
>>> When you start using LLVM as a front end, it throws these clamps out any time
>>> a value in a register gets arithmetically manipulated--preventing the register from
>>> ever having a value outside of the type defined value-space.
>>> <
>>> Unsigned char i = 0;
>>> .......
>>> i++
>>> <
>>> gets compiled to::
>>> <
>>> MOV R19,#0
>>> .......
>>> ADD R19,R19,#1
>>> SLL R19,R19,<8:0>
>>> <
>>> Yes it is ugly......but people should not ask for small types unless they need the small type.
>>>
>> Bit field select, signed and unsigned, is useful, but it's not the same
>> as saturating arithmetic.
> <
> Was not implying that is was or is. One has to do with preventing a value container
> from containing a value outside of the allotted range, the other has to do with pre-
> venting a calculation from delivering a value that is out of range.
>

So do you have a cheap way to do a mul and trap if the result doesn't
fit in 11 bits?

How about to ensure that it is within [-3..542]? That's needed for Ada

Just asking, not challenging; both are problems I've wrestled with in Mill.

On Wednesday, May 12, 2021 at 6:33:51 PM UTC-5, Ivan Godard wrote:
> On 5/12/2021 2:26 PM, BGB wrote:
> > On 5/12/2021 2:53 PM, Ivan Godard wrote:
> >> On 5/12/2021 12:31 PM, MitchAlsup wrote:
> >>
> >>> My 66000 has clamping operations to any bit width--these are a subset
> >>> of the extract instructions (which is itself a subset of the shift
> >>> instruction)
> >>> The classical cases are::
> >>> SLL R8,R8,<8:0> // unsigned char
> >>> SL R8,R8,<8:0> // signed char
> >>> <
> >>> but there are other cases
> >>> <
> >>> SLL R8,R9,<11:0> // 11-bit unsigned bit-field
> >>> SLL R8,R9,<14:13> // 14-bit field from R9<26:13>
> >>> <
> >>> These come in signed (sign extended) and unsigned (zero extended) forms.
> >>> These add exactly ZERO (nada zilch no} instruction to ISA and are in
> >>> fact the
> >>> basis for the shift instructions with the simple rule of::
> >>> width==0 -> width "really =" 64
> >>
> >> But that calls for full width multiply and then a clamp, which is two
> >> instructions' entropy and the dataflow delay, and doesn't actually
> >> clamp the multiply - consider a signed multiply that overflows
> >> (unclamped), and the low order looks to the clamp as a value of the
> >> opposite sign.
> >>
> >> Or have I misunderstood?
> >>
> >
> > Luckily, widening multiply can't overflow...
> >
> > So, say:
> > DMULS R4, R5, R2
> > MOV 2147483647, R6
> > MOV -2147483648, R7
> > CMPQGT R6, R2
> > MOV?T R6, R2
> > CMPQGT R7, R2
> > MOV?F R7, R2
> >
> > But, one doesn't usually clamp each operation, but will rather do a more
> > complex operation, and then clamp the result.
> >
> > But, then one is back to making sure that it can't overflow in any
> > intermediate calculations.
> The problem is that there is always a width for which widening multiply
> is not available, but saturating is possible. If you have wXw->d then
> you're happy until you need to do dXd->sat(d).
<
Big Multiply is an easy problem in My 66000 using CARRY twice, once for
the double width multiply and the second for the double width add.

On Wednesday, May 12, 2021 at 6:39:34 PM UTC-5, Ivan Godard wrote:
> On 5/12/2021 2:27 PM, MitchAlsup wrote:
> > On Wednesday, May 12, 2021 at 2:53:41 PM UTC-5, Ivan Godard wrote:
> >> On 5/12/2021 12:31 PM, MitchAlsup wrote:
> >>
> >>> My 66000 has clamping operations to any bit width--these are a subset
> >>> of the extract instructions (which is itself a subset of the shift instruction)
> >>> The classical cases are::
> >>> SLL R8,R8,<8:0> // unsigned char
> >>> SL R8,R8,<8:0> // signed char
> >>> <
> >>> but there are other cases
> >>> <
> >>> SLL R8,R9,<11:0> // 11-bit unsigned bit-field
> >>> SLL R8,R9,<14:13> // 14-bit field from R9<26:13>
> >>> <
> >>> These come in signed (sign extended) and unsigned (zero extended) forms.
> >>> These add exactly ZERO (nada zilch no} instruction to ISA and are in fact the
> >>> basis for the shift instructions with the simple rule of::
> >>> width==0 -> width "really =" 64
> >> But that calls for full width multiply and then a clamp, which is two
> >> instructions' entropy and the dataflow delay, and doesn't actually clamp
> >> the multiply - consider a signed multiply that overflows (unclamped),
> >> and the low order looks to the clamp as a value of the opposite sign.
> >>
> >> Or have I misunderstood?
> > <
> > clamp means to prevent values from being outside of a range
> > saturate means to prevent a calculation from delivering a value that is out of range.
> > So::
> > uint8_t x = (int64_t)y
> > needs to have the assignment clamped so x has no significance beyond 8-bits.
> > whereas::
> > saturated uint8_t x,y,z;
> > x = y+z;
> > needs to have the addition saturate.
> True; sorry for sloppy terminology.
> >>>>
> >>>> But, never added them...
> >>> <
> >>> I never needed to............
> >>>>
> >>>> Mostly it is an issue of not being common enough (or expensive enough in
> >>>> the naive case) to justify the added cost.
> >>> <
> >>> When you start using LLVM as a front end, it throws these clamps out any time
> >>> a value in a register gets arithmetically manipulated--preventing the register from
> >>> ever having a value outside of the type defined value-space.
> >>> <
> >>> Unsigned char i = 0;
> >>> .......
> >>> i++
> >>> <
> >>> gets compiled to::
> >>> <
> >>> MOV R19,#0
> >>> .......
> >>> ADD R19,R19,#1
> >>> SLL R19,R19,<8:0>
> >>> <
> >>> Yes it is ugly......but people should not ask for small types unless they need the small type.
> >>>
> >> Bit field select, signed and unsigned, is useful, but it's not the same
> >> as saturating arithmetic.
> > <
> > Was not implying that is was or is. One has to do with preventing a value container
> > from containing a value outside of the allotted range, the other has to do with pre-
> > venting a calculation from delivering a value that is out of range.
> >
> So do you have a cheap way to do a mul and trap if the result doesn't
> fit in 11 bits?
<
unsigned:
MUL R8,R13,R19
CMP R9,R8,#1<<11
PCIN R9,<1,1>
TRAP #where_ever
signed:
IMUL R8,R13,R19
ADD R9,R9,#1<<10
CMP R9,R9,#1<<11
PCIN R9,<1,1>
TRAP #where_ever
<
Not excessive, but not great, either.
<
But this is one of the reasons the CMP instruction performs the "within" boundary checks.
which come in 4 flavors:
CIN 0<=x<max // "C" IN
FIN 0<x<=max // FORTRAN IN
RIN 0<=x<=max // Really IN
AIN 0<x<max // Absolutely IN
>
> How about to ensure that it is within [-3..542]? That's needed for Ada
<
Change ADD #1<<11 to ADD #3
Change CMP to #542+3
>
> Just asking, not challenging; both are problems I've wrestled with in Mill.