Thomas Koenig <tkoenig@netcologne.de> schrieb:

> David Brown <david.brown@hesbynett.no> schrieb:
>> On 20/02/2024 07:31, Thomas Koenig wrote:

>>> Even further on the side: I wrote up a proposal for finally
>>> introducing a wrapping UNSIGNED type to Fortran, which hopefully
>>> will be considered in the next J3 meeting, it can be found at
>>> https://j3-fortran.org/doc/year/24/24-102.txt .
>>>
>>> In this proposal, I intended to forbid UNSIGNED variables in
>>> DO loops, especially for this sort of reason.

(Testing a new news server, my old one was decomissioned...)

I was quite delighted, but also a little bit surprised that the
proposal (somewhat modified) actually passed.

Now, what's left is the people who do not want modular arithmetic,
for a reason that I am unable to fathom. I guess they don't like
multiplicative hashes...

On Mon, 11 Mar 2024 18:01:31 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:

> Thomas Koenig <tkoenig@netcologne.de> schrieb:
>
> > David Brown <david.brown@hesbynett.no> schrieb:
> >> On 20/02/2024 07:31, Thomas Koenig wrote:
>
> >>> Even further on the side: I wrote up a proposal for finally
> >>> introducing a wrapping UNSIGNED type to Fortran, which hopefully
> >>> will be considered in the next J3 meeting, it can be found at
> >>> https://j3-fortran.org/doc/year/24/24-102.txt .
> >>>
> >>> In this proposal, I intended to forbid UNSIGNED variables in
> >>> DO loops, especially for this sort of reason.
>
> (Testing a new news server, my old one was decomissioned...)
>
> I was quite delighted, but also a little bit surprised that the
> proposal (somewhat modified) actually passed.
>
> Now, what's left is the people who do not want modular arithmetic,
> for a reason that I am unable to fathom. I guess they don't like
> multiplicative hashes...

What do they like?
To declare unsigned overflow UB? Or implementation defined? Or
trapping?

On 2024-03-11, Michael S <already5chosen@yahoo.com> wrote:
> On Mon, 11 Mar 2024 18:01:31 -0000 (UTC)
> Thomas Koenig <tkoenig@netcologne.de> wrote:
>
>> Thomas Koenig <tkoenig@netcologne.de> schrieb:
>>
>> > David Brown <david.brown@hesbynett.no> schrieb:
>> >> On 20/02/2024 07:31, Thomas Koenig wrote:
>>
>> >>> Even further on the side: I wrote up a proposal for finally
>> >>> introducing a wrapping UNSIGNED type to Fortran, which hopefully
>> >>> will be considered in the next J3 meeting, it can be found at
>> >>> https://j3-fortran.org/doc/year/24/24-102.txt .
>> >>>
>> >>> In this proposal, I intended to forbid UNSIGNED variables in
>> >>> DO loops, especially for this sort of reason.
>>
>> (Testing a new news server, my old one was decomissioned...)
>>
>> I was quite delighted, but also a little bit surprised that the
>> proposal (somewhat modified) actually passed.
>>
>> Now, what's left is the people who do not want modular arithmetic,
>> for a reason that I am unable to fathom. I guess they don't like
>> multiplicative hashes...
>
> What do they like?
> To declare unsigned overflow UB? Or implementation defined? Or
> trapping?

Illegal, hence an implementation would be free to trap or start
World War III (with a bit of an expectation that compilers would
trap when supplied with the right options).

My expecation is different: It would then be treated like signed
overflow, which is also illegal in Fortran. So, everybody will
implement it as if it were modular 2^n anyway, plus start optimizing
on the assumption that overflow cannot happen.

And, since in Fortran, arrays can start at arbitrary lower bounds
(and array can have a lower bound of -42 and an upper bound of -21,
for example), the use of unsigned integers for array indices is
somewhat less than in programming languages such as C or (I believe)
Rust where they always start at zero.

On Mon, 11 Mar 2024 18:19:19 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:

> On 2024-03-11, Michael S <already5chosen@yahoo.com> wrote:
> > On Mon, 11 Mar 2024 18:01:31 -0000 (UTC)
> > Thomas Koenig <tkoenig@netcologne.de> wrote:
> >
> >> Thomas Koenig <tkoenig@netcologne.de> schrieb:
> >>
> >> > David Brown <david.brown@hesbynett.no> schrieb:
> >> >> On 20/02/2024 07:31, Thomas Koenig wrote:
> >>
> >> >>> Even further on the side: I wrote up a proposal for finally
> >> >>> introducing a wrapping UNSIGNED type to Fortran, which
> >> >>> hopefully will be considered in the next J3 meeting, it can be
> >> >>> found at https://j3-fortran.org/doc/year/24/24-102.txt .
> >> >>>
> >> >>> In this proposal, I intended to forbid UNSIGNED variables in
> >> >>> DO loops, especially for this sort of reason.
> >>
> >> (Testing a new news server, my old one was decomissioned...)
> >>
> >> I was quite delighted, but also a little bit surprised that the
> >> proposal (somewhat modified) actually passed.
> >>
> >> Now, what's left is the people who do not want modular arithmetic,
> >> for a reason that I am unable to fathom. I guess they don't like
> >> multiplicative hashes...
> >
> > What do they like?
> > To declare unsigned overflow UB? Or implementation defined? Or
> > trapping?
>
> Illegal, hence an implementation would be free to trap or start
> World War III (with a bit of an expectation that compilers would
> trap when supplied with the right options).
>

So, speaking in C Standard language, UB.

> My expecation is different: It would then be treated like signed
> overflow, which is also illegal in Fortran. So, everybody will
> implement it as if it were modular 2^n anyway, plus start optimizing
> on the assumption that overflow cannot happen.
>

Yes, I'd expect the same.

> And, since in Fortran, arrays can start at arbitrary lower bounds
> (and array can have a lower bound of -42 and an upper bound of -21,
> for example), the use of unsigned integers for array indices is
> somewhat less than in programming languages such as C or (I believe)
> Rust where they always start at zero.

As discussed here just recently, there are good reason to avoid
'unsigned' array indices in performance-oriented programs running under
IL32P64 or I32LP64 C environments. Everything else is preferable -
int, ptrdiff_t, size_t. Now, opinions on which of the 3 is most
preferable, tend to vary.

What is the size of Fortran's default UNSIGNED ?

On 11/03/2024 19:10, Michael S wrote:
> On Mon, 11 Mar 2024 18:01:31 -0000 (UTC)
> Thomas Koenig <tkoenig@netcologne.de> wrote:
>
>> Thomas Koenig <tkoenig@netcologne.de> schrieb:
>>
>>> David Brown <david.brown@hesbynett.no> schrieb:
>>>> On 20/02/2024 07:31, Thomas Koenig wrote:
>>
>>>>> Even further on the side: I wrote up a proposal for finally
>>>>> introducing a wrapping UNSIGNED type to Fortran, which hopefully
>>>>> will be considered in the next J3 meeting, it can be found at
>>>>> https://j3-fortran.org/doc/year/24/24-102.txt .
>>>>>
>>>>> In this proposal, I intended to forbid UNSIGNED variables in
>>>>> DO loops, especially for this sort of reason.
>>
>> (Testing a new news server, my old one was decomissioned...)
>>
>> I was quite delighted, but also a little bit surprised that the
>> proposal (somewhat modified) actually passed.
>>
>> Now, what's left is the people who do not want modular arithmetic,
>> for a reason that I am unable to fathom. I guess they don't like
>> multiplicative hashes...
>
> What do they like?
> To declare unsigned overflow UB? Or implementation defined? Or
> trapping?
>

Speaking for myself only, I'd like a choice. For the most part, I
consider overflow (signed or unsigned) to indicate an error in the code.
The two appropriate actions then are a run-time error, or that the
compiler assumes that such overflow does not happen for the purposes of
optimisation. (Whether the choice of handling here is determined by the
source code, or compiler options, or a combination of both, is another
matter of choice.) And for some unusual code, I want overflow (signed
or unsigned) to be defined behaviour - either wrapping, or with
additional information about overflows or carries, or perhaps more
special cases such as saturation.

Basically, I think it is a mistake for a language to pick one kind of
treatment and pretend that this is /the/ correct handling of overflow.
Different circumstances could call for a variety of different behaviours.

If I had to pick only one possible choice of treatment, then I suppose
it would be wrapping - because sometimes you really need that in code,
while UB based optimisation or run-time checking is just "nice to have"
rather than essential. Standard C having UB for signed overflow and
wrapping for unsigned overflow is a reasonable compromise when keeping
things simple, but I'd prefer a choice.

(Similarly, I'd prefer a choice regarding another favourite source of UB
and complaints in C - that of type-based alias analysis. I'd sometimes
like 16-bit, 32-bit and 64-bit types that could alias anything, and I'd
sometimes like 8-bit types that did /not/ alias anything.)

David Brown wrote:

> On 23/02/2024 20:55, MitchAlsup1 wrote:
>> Thomas Koenig wrote:
>>
>>> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>>>> I know no implementation of a 64-bit architecture where ALU operations
>>>> (except maybe division where present) is slower in 64 bits than in 32
>>>> bits.  I would have chosen ILP64 at the time, so I can only guess at
>>>> their reasons:
>>
>>> A guess: people did not want sizeof(float) != sizeof(float). float
>>> is cerainly faster than double.
>>
>> Now, only in cache footprint. All your std operations take the same amount
>> of cycles DP vs. SP. Excepting for cache footprint latency:: perf(DP) ==
>> perf(SP)
>>

> That's true - except when it is not.

> It is not true when you are using vector instructions, and you can do
> twice as many SP instructions as DP instructions in the same register
> and instruction.

You use the word vector where you mean SIMD. A CRAY-YMP doing single
would not be twice as fast because it was designed for 1 FADD + 1 FMUL
+ 2 LD + 1 ST per cycle continuously. CRAY-YMP is the epitome of a
Vector machine.

The alternative word would be short-vector instead of SIMD.

> It is not true when you are using accelerators of various kinds, such as
> graphics card processors.

> And it is not true on smaller processors, such as in the embedded world.
> On microcontrollers with floating point hardware for single and double
> precision, SP can be up to twice as fast as DP. And for many of the
> more popular microcontrollers, you can have hardware SP but DP is done
> in software - the difference there is clearly massive.

> But for big processors doing non-vector adds and multiplies, DP and SP
> are usually equal in clock cycles (other than memory and cache effects).

Terje Mathisen wrote:

> Thomas Koenig wrote:
>> MitchAlsup1 <mitchalsup@aol.com> schrieb:
>>> Thomas Koenig wrote:
>>>
>>>> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>>>>> I know no implementation of a 64-bit architecture where ALU operations
>>>>> (except maybe division where present) is slower in 64 bits than in 32
>>>>> bits. I would have chosen ILP64 at the time, so I can only guess at
>>>>> their reasons:
>>>
>>>> A guess: people did not want sizeof(float) != sizeof(float). float
>>>> is cerainly faster than double.
>>>
>>> Now, only in cache footprint. All your std operations take the same amount
>>> of cycles DP vs. SP. Excepting for cache footprint latency::
>>> perf(DP) == perf(SP)

> FDIV float vs double is still quite often slightly faster, but not close
> to 2 X faster even though the mantissa is only 24/53 as large.

On a machine where DDIV takes 17 cycles, SDIV would take 15 both using
Goldschmidt algorithm with a Newton-Raphson fix up at the end.
On a machine using SRT Division, single is about twice as fast as
double.

> Terje

On 2024-02-25, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
>>
>>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>>
>>>> Signed integer overflow is undefined behavior in C and prohibited
>>>> in Fortran. Yet, there is no straightforward, standard-compliant
>>>> way to check for signed overflow (and handle this appropriately)
>>>> in either language. [...]
>>>
>>> It isn't hard to write standard C code to determine whether a
>>> proposed addition or subtraction would overflow, and does so
>>> safely and reliably.
>>
>> Also efficiently and without resorting to implementation-
>> defined or undefined behavior (and without needing a bigger
>> type)?

[...]

> Heavens to Betsy! Are you impugning the quality and excellence
> of my code? Of *my* code? I can only hope that you are suitably
> chagrined and contrite. ;)
>
>>> It's a little bit tedious perhaps but not
>>> difficult. Checking code can be wrapped in an inline function
>>> and invoke whatever handling is desired, within reason.
>>
>> Maybe you could share such code?
>
> Rather that do that I will explain.
>
> An addition overflows if the two operands have the same sign and
> the sign of an operand is the opposite of the sign of the sum
> (taken mod the width of the operands). Convert the signed
> operands to their unsigned counterparts, and form the sum of the
> unsigned values. The sign is just the high-order bit in each
> case. Thus the overflow condition can be detected with a few
> bitwise xors and ands.
>
> Subtraction is similar except now overflow can occur only when
> the operands have different signs and the sign of the sum is
> the opposite of the sign of the first operand.
>
> The above description works for two's complement hardware where
> unsigned types have the same width as their corresponding signed
> types. I think for most people that's all they need. The three
> other possibilities are all doable with minor adjustments, and
> code appropriate to each particular implementation can be
> selected using C preprocessor conditional, as for example

....

but that's implementation-defined behavior, correct?

On 2024-03-11, Michael S <already5chosen@yahoo.com> wrote:
> On Mon, 11 Mar 2024 18:19:19 -0000 (UTC)
> Thomas Koenig <tkoenig@netcologne.de> wrote:
>
>> On 2024-03-11, Michael S <already5chosen@yahoo.com> wrote:
>> > On Mon, 11 Mar 2024 18:01:31 -0000 (UTC)
>> > Thomas Koenig <tkoenig@netcologne.de> wrote:
>> >
>> >> Thomas Koenig <tkoenig@netcologne.de> schrieb:
>> >>
>> >> > David Brown <david.brown@hesbynett.no> schrieb:
>> >> >> On 20/02/2024 07:31, Thomas Koenig wrote:
>> >>
>> >> >>> Even further on the side: I wrote up a proposal for finally
>> >> >>> introducing a wrapping UNSIGNED type to Fortran, which
>> >> >>> hopefully will be considered in the next J3 meeting, it can be
>> >> >>> found at https://j3-fortran.org/doc/year/24/24-102.txt .
>> >> >>>
>> >> >>> In this proposal, I intended to forbid UNSIGNED variables in
>> >> >>> DO loops, especially for this sort of reason.
>> >>
>> >> (Testing a new news server, my old one was decomissioned...)
>> >>
>> >> I was quite delighted, but also a little bit surprised that the
>> >> proposal (somewhat modified) actually passed.
>> >>
>> >> Now, what's left is the people who do not want modular arithmetic,
>> >> for a reason that I am unable to fathom. I guess they don't like
>> >> multiplicative hashes...
>> >
>> > What do they like?
>> > To declare unsigned overflow UB? Or implementation defined? Or
>> > trapping?
>>
>> Illegal, hence an implementation would be free to trap or start
>> World War III (with a bit of an expectation that compilers would
>> trap when supplied with the right options).
>>
>
> So, speaking in C Standard language, UB.

Yes, that would be the translation. In Fortran terms, it would
violate a "shall" directive.

>
>
>> My expecation is different: It would then be treated like signed
>> overflow, which is also illegal in Fortran. So, everybody will
>> implement it as if it were modular 2^n anyway, plus start optimizing
>> on the assumption that overflow cannot happen.
>>
>
> Yes, I'd expect the same.
>
>> And, since in Fortran, arrays can start at arbitrary lower bounds
>> (and array can have a lower bound of -42 and an upper bound of -21,
>> for example), the use of unsigned integers for array indices is
>> somewhat less than in programming languages such as C or (I believe)
>> Rust where they always start at zero.
>
> As discussed here just recently, there are good reason to avoid
> 'unsigned' array indices in performance-oriented programs running under
> IL32P64 or I32LP64 C environments. Everything else is preferable -
> int, ptrdiff_t, size_t. Now, opinions on which of the 3 is most
> preferable, tend to vary.
>
> What is the size of Fortran's default UNSIGNED ?

It is not yet in the language; a paper has been passed by J3,
but it needs to be put to WG5, and WG5 has to agree that J3 should
put it into the standard proper for Fortran 202y (202x just
came out as Fortran 2023).

But if it does go in, it is likely that it will have the same
size as INTEGER, which is usually 32 bits.

However, what I did put in the paper (and what the subsequent
revision by a J3 subcommittee left in) is a prohibition against
using unsigneds in a DO loop. The reason is semantics of
negative strides.

Currently, in Fortran, the number of iterations of the loop

do i=m1,m2,m3
....
end do

is (m2-m1+m3)/m3 unless that value is negative, in which case it
is zero (m3 defaults to 1 if it is not present).

So,

do i=1,3,-1

will be executed zero times, as will

do i=3,1

Translating that into arithmetic with unsigned integers makes
little sense, how many times should

do i=1,3,4294967295

be executed?

Thomas Koenig wrote:

> On 2024-03-11, Michael S <already5chosen@yahoo.com> wrote:
>> On Mon, 11 Mar 2024 18:19:19 -0000 (UTC)
>> Thomas Koenig <tkoenig@netcologne.de> wrote:
>>
>>> On 2024-03-11, Michael S <already5chosen@yahoo.com> wrote:
>>> > On Mon, 11 Mar 2024 18:01:31 -0000 (UTC)
>>> > Thomas Koenig <tkoenig@netcologne.de> wrote:
>>> >
>>> >> Thomas Koenig <tkoenig@netcologne.de> schrieb:
>>> >>
>>> >> > David Brown <david.brown@hesbynett.no> schrieb:
>>> >> >> On 20/02/2024 07:31, Thomas Koenig wrote:
>>> >>
>>> >> >>> Even further on the side: I wrote up a proposal for finally
>>> >> >>> introducing a wrapping UNSIGNED type to Fortran, which
>>> >> >>> hopefully will be considered in the next J3 meeting, it can be
>>> >> >>> found at https://j3-fortran.org/doc/year/24/24-102.txt .
>>> >> >>>
>>> >> >>> In this proposal, I intended to forbid UNSIGNED variables in
>>> >> >>> DO loops, especially for this sort of reason.
>>> >>
>>> >> (Testing a new news server, my old one was decomissioned...)
>>> >>
>>> >> I was quite delighted, but also a little bit surprised that the
>>> >> proposal (somewhat modified) actually passed.
>>> >>
>>> >> Now, what's left is the people who do not want modular arithmetic,
>>> >> for a reason that I am unable to fathom. I guess they don't like
>>> >> multiplicative hashes...
>>> >
>>> > What do they like?
>>> > To declare unsigned overflow UB? Or implementation defined? Or
>>> > trapping?
>>>
>>> Illegal, hence an implementation would be free to trap or start
>>> World War III (with a bit of an expectation that compilers would
>>> trap when supplied with the right options).
>>>
>>
>> So, speaking in C Standard language, UB.

> Yes, that would be the translation. In Fortran terms, it would
> violate a "shall" directive.

>>
>>
>>> My expecation is different: It would then be treated like signed
>>> overflow, which is also illegal in Fortran. So, everybody will
>>> implement it as if it were modular 2^n anyway, plus start optimizing
>>> on the assumption that overflow cannot happen.
>>>
>>
>> Yes, I'd expect the same.
>>
>>> And, since in Fortran, arrays can start at arbitrary lower bounds
>>> (and array can have a lower bound of -42 and an upper bound of -21,
>>> for example), the use of unsigned integers for array indices is
>>> somewhat less than in programming languages such as C or (I believe)
>>> Rust where they always start at zero.
>>
>> As discussed here just recently, there are good reason to avoid
>> 'unsigned' array indices in performance-oriented programs running under
>> IL32P64 or I32LP64 C environments. Everything else is preferable -
>> int, ptrdiff_t, size_t. Now, opinions on which of the 3 is most
>> preferable, tend to vary.
>>
>> What is the size of Fortran's default UNSIGNED ?

> It is not yet in the language; a paper has been passed by J3,
> but it needs to be put to WG5, and WG5 has to agree that J3 should
> put it into the standard proper for Fortran 202y (202x just
> came out as Fortran 2023).

> But if it does go in, it is likely that it will have the same
> size as INTEGER, which is usually 32 bits.

> However, what I did put in the paper (and what the subsequent
> revision by a J3 subcommittee left in) is a prohibition against
> using unsigneds in a DO loop. The reason is semantics of
> negative strides.

> Currently, in Fortran, the number of iterations of the loop

> do i=m1,m2,m3
> ....
> end do

> is (m2-m1+m3)/m3 unless that value is negative, in which case it
> is zero (m3 defaults to 1 if it is not present).

> So,

> do i=1,3,-1

> will be executed zero times, as will

> do i=3,1

> Translating that into arithmetic with unsigned integers makes
> little sense, how many times should

> do i=1,3,4294967295

> be executed?

3-1+4294967295 = 4294967297 // (m2-m1+m3)

4294967297 / 4294967295 = 1.0000000004656612874161594750863

So the loop should be executed one time. {{And yes I know 4294967295 ==
0x1,0000,0001}} What would you expect on a 36-bit machine (2s-complement)
where 4294967295 is representable naturally ??

Do i = 1 incrementing by 4294967295 until i > 3 should be executed once.
Certainly 1 is <= 3 in any numeric system so it should be executed at least
once.
Certainly 1+4294967295 > 3 in any numeric system claiming to be algebraic,
and additionally when registers are larger than
32-bits. So the loop should not be executed more
than once.

This happens naturally on a 64-bit machine and on 64-bit machines which do
not have word-width calculation instructions. If you use the word width
instructions you enter in to UB or IB behavior.

MitchAlsup1 <mitchalsup@aol.com> schrieb:
> Thomas Koenig wrote:

>> However, what I did put in the paper (and what the subsequent
>> revision by a J3 subcommittee left in) is a prohibition against
>> using unsigneds in a DO loop. The reason is semantics of
>> negative strides.
>
>> Currently, in Fortran, the number of iterations of the loop
>
>> do i=m1,m2,m3
>> ....
>> end do
>
>> is (m2-m1+m3)/m3 unless that value is negative, in which case it
>> is zero (m3 defaults to 1 if it is not present).
>
>> So,
>
>> do i=1,3,-1
>
>> will be executed zero times, as will
>
>> do i=3,1
>
>> Translating that into arithmetic with unsigned integers makes
>> little sense, how many times should
>
>> do i=1,3,4294967295
>
>> be executed?
>
> 3-1+4294967295 = 4294967297 // (m2-m1+m3)
>
> 4294967297 / 4294967295 = 1.0000000004656612874161594750863
>
> So the loop should be executed one time. {{And yes I know 4294967295 ==
> 0x1,0000,0001}} What would you expect on a 36-bit machine (2s-complement)
> where 4294967295 is representable naturally ??

Correct (of course).

The same result would be expected for

do i=1u,3u,-1u

(asusming an u suffix for unsigned numbers).

The problem is that this violates a Fortran basic assumption since
FORTRAN 77, which is that DO loops can be zero-trip.

This is a can of worms that I would like to leave unopened.

Same goes for array slices. Even assuming that no negative
indices are used, the slice a(1:3:-1) is zero-sized in Fortran,
as is a(3:1) .

For a(1u:3u:-1u) the same logic that you outlined above would apply,
making it a slice with one element.

Not going there :-)

On 11/03/2024 22:29, Thomas Koenig wrote:
> On 2024-02-25, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

>> The above description works for two's complement hardware where
>> unsigned types have the same width as their corresponding signed
>> types. I think for most people that's all they need. The three
>> other possibilities are all doable with minor adjustments, and
>> code appropriate to each particular implementation can be
>> selected using C preprocessor conditional, as for example
>
> ...
>
> but that's implementation-defined behavior, correct?

It is, as far as I understand it. (Tim knows these things better than I
do, so if he finds something in the standards to contradict me, he's
probably right.)

For a signed integer type T in C, you have N value bits, P padding bits,
and a single sign bit. The N value bits can hold values between 0 and
2^N - 1. The sign bit can either indicate a negative value (sign and
magnitude), -2^N (two's complement), or -(2^N - 1) (ones' complement).
There will also be a corresponding unsigned type, which has at least N
value bits and takes the same number of bytes, and has no sign bit. It
can still have padding bits (except for unsigned char, which has no
padding). But all non-negative integers that can be represented in the
signed type have exactly the same significant bits in both the signed
and unsigned types.

So an implementation can have a 32-bit two's complement "int", and use
that for unsigned types too, treating the MSB as a padding bit for
unsigned usage. (Of course, doing so would be inefficient in use on
most cpus - you'd have to keep masking off the padding bit when using
the value, or somehow guarantee that it is never non-zero.)

In such an implementation, converting an int to an unsigned int would
mask off the top bit (fully defined by the standard), and converting
from an unsigned int it to a signed int would leave it unchanged
(implementation dependent in the standard). That means (int)(unsigned
int)(-1) would be positive 0x7fffffff, not -1.

Real-world systems, of course, all use two's complement types with no
padding, and Tim's description will work fine.

(And in C23, only two's complement representations will be allowed. I
can't remember if padding bits are still allowed, however. And of
course signed integer overflow is still UB.)

Michael S <already5chosen@yahoo.com> writes:
>As discussed here just recently, there are good reason to avoid
>'unsigned' array indices in performance-oriented programs running under
>IL32P64 or I32LP64 C environments. Everything else is preferable -
>int, ptrdiff_t, size_t.

If Fortran makes unsigned overflow illegal, Fortran compilers can
perform the same shenanigans for unsigned that C compilers do for
signed integers; so if signed int really is preferable because of
these shenanigans, unsigned with the same shenanigans would be
preferable, too.

In general, I think that undersized ints (as in I32LP64 or IL32P64)
are always at a disadvantage; some architectures (particularly ARM
A64) go to extra lengths to compensate for these disadvantages, but I
don't think that these measures eliminates it completely, and the
additional effort in the architectures could have gone to better uses.

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

Tim Rentsch wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>
>> If I really had to write a 64x64->128 MUL, with no widening MUL or
>> MULH which returns the high half, then I would punt and do it using
>> 32-bit parts (all variables are u64): [...]
>
> I wrote some code along the same lines. A difference is you
> are considering unsigned multiplication, and I am considering
> signed multiplication.
>
Signed mul is just a special case of unsigned mul, right?

I.e. in case of a signed widening mul, you'd first extract the signs,
convert the inputs to unsigned, then do the unsigned widening mul,
before finally resotirng the sign as the XOR of the input signs?

There is a small gotcha if either of the inputs are of the 0x80000000
form, i.e. MININT, but the naive iabs() conversion will do the right
thing by leaving the input unchanged.

At the other end there cannot be any issues since restoring a negative
output sign cannot overflow/fail.

Terje

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

On 11/03/2024 20:56, MitchAlsup1 wrote:
> David Brown wrote:
>
>> On 23/02/2024 20:55, MitchAlsup1 wrote:
>>> Thomas Koenig wrote:
>>>
>>>> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>>>>> I know no implementation of a 64-bit architecture where ALU operations
>>>>> (except maybe division where present) is slower in 64 bits than in 32
>>>>> bits.  I would have chosen ILP64 at the time, so I can only guess at
>>>>> their reasons:
>>>
>>>> A guess: people did not want sizeof(float) != sizeof(float). float
>>>> is cerainly faster than double.
>>>
>>> Now, only in cache footprint. All your std operations take the same
>>> amount
>>> of cycles DP vs. SP. Excepting for cache footprint latency:: perf(DP)
>>> == perf(SP)
>>>
>
>> That's true - except when it is not.
>
>> It is not true when you are using vector instructions, and you can do
>> twice as many SP instructions as DP instructions in the same register
>> and instruction.
>
> You use the word vector where you mean SIMD.

Yes, I was using the word somewhat interchangeably, as I was talking in
general terms. Perhaps I should have been more precise. I know this
thread talked about "Cray style vectors", but I thought this branch had
diverged - I don't know anywhere near enough about the details of Cray
machines to talk much about them.

> A CRAY-YMP doing single
> would not be twice as fast because it was designed for 1 FADD + 1 FMUL +
> 2 LD + 1 ST per cycle continuously. CRAY-YMP is the epitome of a
> Vector machine.
>
> The alternative word would be short-vector instead of SIMD.
>
>> It is not true when you are using accelerators of various kinds, such
>> as graphics card processors.
>
>> And it is not true on smaller processors, such as in the embedded
>> world.   On microcontrollers with floating point hardware for single
>> and double precision, SP can be up to twice as fast as DP.  And for
>> many of the more popular microcontrollers, you can have hardware SP
>> but DP is done in software - the difference there is clearly massive.
>
>> But for big processors doing non-vector adds and multiplies, DP and SP
>> are usually equal in clock cycles (other than memory and cache effects).

On Tue, 12 Mar 2024 11:14:47 +0100
David Brown <david.brown@hesbynett.no> wrote:

> On 11/03/2024 20:56, MitchAlsup1 wrote:
> > David Brown wrote:
> >
> >> On 23/02/2024 20:55, MitchAlsup1 wrote:
> >>> Thomas Koenig wrote:
> >>>
> >>>> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
> >>>>> I know no implementation of a 64-bit architecture where ALU
> >>>>> operations (except maybe division where present) is slower in
> >>>>> 64 bits than in 32 bits.  I would have chosen ILP64 at the
> >>>>> time, so I can only guess at their reasons:
> >>>
> >>>> A guess: people did not want sizeof(float) != sizeof(float).
> >>>> float is cerainly faster than double.
> >>>
> >>> Now, only in cache footprint. All your std operations take the
> >>> same amount
> >>> of cycles DP vs. SP. Excepting for cache footprint latency::
> >>> perf(DP) == perf(SP)
> >>>
> >
> >> That's true - except when it is not.
> >
> >> It is not true when you are using vector instructions, and you can
> >> do twice as many SP instructions as DP instructions in the same
> >> register and instruction.
> >
> > You use the word vector where you mean SIMD.
>
> Yes, I was using the word somewhat interchangeably, as I was talking
> in general terms. Perhaps I should have been more precise. I know
> this thread talked about "Cray style vectors", but I thought this
> branch had diverged - I don't know anywhere near enough about the
> details of Cray machines to talk much about them.
>

Even for Cray/NEC-style vectors, the same throughput for different
precision is not an universal property. Cray's and NEC's vector
processors happen to be designed like that, but one can easily imagine
vector processors of similar style that have 2 or even 3 times higher
throughput for SP vs DP.
I personally never encountered such machines, but would be surprised if
it were never built and sold back by one or another usual suspect (may
be, Fujitsu?) in days when designers liked Cray's style.

Which, of course, leaves the question of what property makes vector
processor Cray-style. Just having ALU/FPU several times narrower than
VR is, IMHO, not enough to be considered Cray-style.
In my book, the critical distinction is that at least one size of
partial (chopped) none-load-store vector operations has higher
throughput (and hopefully, but not necessarily lower latency) than full
vector operations of the same type.

> > A CRAY-YMP doing single
> > would not be twice as fast because it was designed for 1 FADD + 1
> > FMUL + 2 LD + 1 ST per cycle continuously. CRAY-YMP is the epitome
> > of a Vector machine.
> >
> > The alternative word would be short-vector instead of SIMD.
> >
> >> It is not true when you are using accelerators of various kinds,
> >> such as graphics card processors.
> >
> >> And it is not true on smaller processors, such as in the embedded
> >> world.   On microcontrollers with floating point hardware for
> >> single and double precision, SP can be up to twice as fast as DP.
> >> And for many of the more popular microcontrollers, you can have
> >> hardware SP but DP is done in software - the difference there is
> >> clearly massive.
> >
> >> But for big processors doing non-vector adds and multiplies, DP
> >> and SP are usually equal in clock cycles (other than memory and
> >> cache effects).
>

Terje Mathisen wrote:

> Tim Rentsch wrote:
>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>
>>> If I really had to write a 64x64->128 MUL, with no widening MUL or
>>> MULH which returns the high half, then I would punt and do it using
>>> 32-bit parts (all variables are u64): [...]
>>
>> I wrote some code along the same lines. A difference is you
>> are considering unsigned multiplication, and I am considering
>> signed multiplication.
>>
> Signed mul is just a special case of unsigned mul, right?

The low order N bits are all the same while the higher order N bits
are different; where N is operand size.

> I.e. in case of a signed widening mul, you'd first extract the signs,
> convert the inputs to unsigned, then do the unsigned widening mul,
> before finally resotirng the sign as the XOR of the input signs?

SW may have to do that, HW does not.

> There is a small gotcha if either of the inputs are of the 0x80000000
> form, i.e. MININT, but the naive iabs() conversion will do the right
> thing by leaving the input unchanged.

> At the other end there cannot be any issues since restoring a negative
> output sign cannot overflow/fail.

> Terje

Michael S wrote:

> On Tue, 12 Mar 2024 11:14:47 +0100
> David Brown <david.brown@hesbynett.no> wrote:

>> >
>> > You use the word vector where you mean SIMD.
>>
>> Yes, I was using the word somewhat interchangeably, as I was talking
>> in general terms. Perhaps I should have been more precise. I know
>> this thread talked about "Cray style vectors", but I thought this
>> branch had diverged - I don't know anywhere near enough about the
>> details of Cray machines to talk much about them.
>>

> Even for Cray/NEC-style vectors, the same throughput for different
> precision is not an universal property. Cray's and NEC's vector
> processors happen to be designed like that, but one can easily imagine
> vector processors of similar style that have 2 or even 3 times higher
> throughput for SP vs DP.
> I personally never encountered such machines, but would be surprised if
> it were never built and sold back by one or another usual suspect (may
> be, Fujitsu?) in days when designers liked Cray's style.

While theoretically possible, they did not do this because both halves
of a 2×SP would not arrive from memory necessarily simultaneously.
{Consider a gather load you need a vector of addresses 2× as long
for pairs of SP going into a single vector register element.}

> Which, of course, leaves the question of what property makes vector
> processor Cray-style. Just having ALU/FPU several times narrower than
> VR is, IMHO, not enough to be considered Cray-style.

That property is that the length of the vector register is chosen to
absorb the latency to memory. SMID is too short to have this property.

> In my book, the critical distinction is that at least one size of
> partial (chopped) none-load-store vector operations has higher
> throughput (and hopefully, but not necessarily lower latency) than full
> vector operations of the same type.

On Tue, 12 Mar 2024 17:18:36 +0000
mitchalsup@aol.com (MitchAlsup1) wrote:

> Michael S wrote:
>
> > On Tue, 12 Mar 2024 11:14:47 +0100
> > David Brown <david.brown@hesbynett.no> wrote:
>
> >> >
> >> > You use the word vector where you mean SIMD.
> >>
> >> Yes, I was using the word somewhat interchangeably, as I was
> >> talking in general terms. Perhaps I should have been more
> >> precise. I know this thread talked about "Cray style vectors",
> >> but I thought this branch had diverged - I don't know anywhere
> >> near enough about the details of Cray machines to talk much about
> >> them.
>
> > Even for Cray/NEC-style vectors, the same throughput for different
> > precision is not an universal property. Cray's and NEC's vector
> > processors happen to be designed like that, but one can easily
> > imagine vector processors of similar style that have 2 or even 3
> > times higher throughput for SP vs DP.
> > I personally never encountered such machines, but would be
> > surprised if it were never built and sold back by one or another
> > usual suspect (may be, Fujitsu?) in days when designers liked
> > Cray's style.
>
> While theoretically possible, they did not do this because both halves
> of a 2×SP would not arrive from memory necessarily simultaneously.
> {Consider a gather load you need a vector of addresses 2× as long
> for pairs of SP going into a single vector register element.}
>

Doctor, it hurts when I do this!
So, what prevents you from providing no gather with resolution
below 64 bits?

> > Which, of course, leaves the question of what property makes vector
> > processor Cray-style. Just having ALU/FPU several times narrower
> > than VR is, IMHO, not enough to be considered Cray-style.
>
> That property is that the length of the vector register is chosen to
> absorb the latency to memory. SMID is too short to have this property.
>

I don't like this definition at all.
For starter, what is "memory"? Does L1D cache count, or only L2 and
higher?
Then, what is "absorb" ? Is the whole VR register file part of
absorbent or latency should be covered by one register? Is OoO machinery
part of absorbent? Is HW threading part of absorbent? And for any of
your possible answers I have my "Why?".

> > In my book, the critical distinction is that at least one size of
> > partial (chopped) none-load-store vector operations has higher
> > throughput (and hopefully, but not necessarily lower latency) than
> > full vector operations of the same type.

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

> Tim Rentsch wrote:
>
>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>
>>> If I really had to write a 64x64->128 MUL, with no widening MUL or
>>> MULH which returns the high half, then I would punt and do it using
>>> 32-bit parts (all variables are u64): [...]
>>
>> I wrote some code along the same lines. A difference is you
>> are considering unsigned multiplication, and I am considering
>> signed multiplication.
>
> Signed mul is just a special case of unsigned mul, right?
>
> I.e. in case of a signed widening mul, you'd first extract the signs,
> convert the inputs to unsigned, then do the unsigned widening mul,
> before finally resotirng the sign as the XOR of the input signs?
>
> There is a small gotcha if either of the inputs are of the 0x80000000
> form, i.e. MININT, but the naive iabs() conversion will do the right
> thing by leaving the input unchanged.
>
> At the other end there cannot be any issues since restoring a negative
> output sign cannot overflow/fail.

It isn't quite that simple. Some of what you describe has a risk
of running afoul of implementation-defined behavior or undefined
behavior (as for example abs( INT_MIN )). I'm pretty sure it's
possible to avoid those pitfalls, but it requires a fair amount
of care and careful thinking.

Note that my goal is only to avoid the possibility of undefined
behavior that comes from signed overflow. My approach is to safely
determine whether the signed multiplication would overflow, and if
it wouldn't then simply use signed arithmetic to get the result.
I use unsigned types to determine the safety, and if it's safe then
using signed types to get a result. For the current problem I don't
care about widening, except as it might help to determine safety.

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
> Michael S <already5chosen@yahoo.com> writes:
>>As discussed here just recently, there are good reason to avoid
>>'unsigned' array indices in performance-oriented programs running under
>>IL32P64 or I32LP64 C environments. Everything else is preferable -
>>int, ptrdiff_t, size_t.
>
> If Fortran makes unsigned overflow illegal, Fortran compilers can
> perform the same shenanigans for unsigned that C compilers do for
> signed integers; so if signed int really is preferable because of
> these shenanigans, unsigned with the same shenanigans would be
> preferable, too.

One problem is that, without 2^n modulo, something like a
multiplicative hash would be illegal.

People would do it anyway, ignoring the prohibition, because it
is so useful, and subsequent hilarity will ensue.

Thomas Koenig <tkoenig@netcologne.de> writes:

> On 2024-02-25, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
>>>
>>>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>>>
>>>>> Signed integer overflow is undefined behavior in C and prohibited
>>>>> in Fortran. Yet, there is no straightforward, standard-compliant
>>>>> way to check for signed overflow (and handle this appropriately)
>>>>> in either language. [...]
>>>>
>>>> It isn't hard to write standard C code to determine whether a
>>>> proposed addition or subtraction would overflow, and does so
>>>> safely and reliably.
>>>
>>> Also efficiently and without resorting to implementation-
>>> defined or undefined behavior (and without needing a bigger
>>> type)?
>
> [...]
>
>> Heavens to Betsy! Are you impugning the quality and excellence
>> of my code? Of *my* code? I can only hope that you are suitably
>> chagrined and contrite. ;)
>>
>>>> It's a little bit tedious perhaps but not
>>>> difficult. Checking code can be wrapped in an inline function
>>>> and invoke whatever handling is desired, within reason.
>>>
>>> Maybe you could share such code?
>>
>> Rather that do that I will explain.
>>
>> An addition overflows if the two operands have the same sign and
>> the sign of an operand is the opposite of the sign of the sum
>> (taken mod the width of the operands). Convert the signed
>> operands to their unsigned counterparts, and form the sum of the
>> unsigned values. The sign is just the high-order bit in each
>> case. Thus the overflow condition can be detected with a few
>> bitwise xors and ands.
>>
>> Subtraction is similar except now overflow can occur only when
>> the operands have different signs and the sign of the sum is
>> the opposite of the sign of the first operand.
>>
>> The above description works for two's complement hardware where
>> unsigned types have the same width as their corresponding signed
>> types. I think for most people that's all they need. The three
>> other possibilities are all doable with minor adjustments, and
>> code appropriate to each particular implementation can be
>> selected using C preprocessor conditional, as for example
>
> ...
>
> but that's implementation-defined behavior, correct?

There is implementation-dependent behavior but there isn't any
implementation-defined behavior. The result has to depend on the
implementation because different implementations can imply
different results, as for example whether the representation for
signed integers uses two's complement or ones' complement.
Roughly speaking the distinction is whether code is relying on an
implementation choice other than the choice assumed. There is
nothing wrong, for example, with code that holds the value of the
character constant 'a' in a variable, as long as the code makes
sure that there are no wrong assumptions about what specific
value that is (as for example the wrong assumption that the
expression c + "A" - "a" can be used to change a letter from
lower case to upper case). The C standard doesn't clearly
differentiate behavior /of the implementation/ and behavior /of
the program/. I took your question to mean, Does the code resort
to implementation-defined behavior so as to rely on an unreliable
assumption, ie, the kind that can go wrong if a different
implementation-defined choice is made? The answer is that the
code does not rely on any such assumption. So strictly speaking
the code does /involve/ implementation-defined choices (as indeed
essentially all programs do). But it does not /depend/ on
implementation-defined choices in any way that risks changing the
correctness of its results.

Michael S wrote:

> On Tue, 12 Mar 2024 17:18:36 +0000
> mitchalsup@aol.com (MitchAlsup1) wrote:

>> Michael S wrote:
>>
>> > On Tue, 12 Mar 2024 11:14:47 +0100
>> > David Brown <david.brown@hesbynett.no> wrote:
>>
>> >> >
>> >> > You use the word vector where you mean SIMD.
>> >>
>> >> Yes, I was using the word somewhat interchangeably, as I was
>> >> talking in general terms. Perhaps I should have been more
>> >> precise. I know this thread talked about "Cray style vectors",
>> >> but I thought this branch had diverged - I don't know anywhere
>> >> near enough about the details of Cray machines to talk much about
>> >> them.
>>
>> > Even for Cray/NEC-style vectors, the same throughput for different
>> > precision is not an universal property. Cray's and NEC's vector
>> > processors happen to be designed like that, but one can easily
>> > imagine vector processors of similar style that have 2 or even 3
>> > times higher throughput for SP vs DP.
>> > I personally never encountered such machines, but would be
>> > surprised if it were never built and sold back by one or another
>> > usual suspect (may be, Fujitsu?) in days when designers liked
>> > Cray's style.
>>
>> While theoretically possible, they did not do this because both halves
>> of a 2×SP would not arrive from memory necessarily simultaneously.
>> {Consider a gather load you need a vector of addresses 2× as long
>> for pairs of SP going into a single vector register element.}
>>

> Doctor, it hurts when I do this!
> So, what prevents you from providing no gather with resolution
> below 64 bits?

Well, then, you have SP values in a container than could hold 2 and you
don't get any SIMD speedup.

>> > Which, of course, leaves the question of what property makes vector
>> > processor Cray-style. Just having ALU/FPU several times narrower
>> > than VR is, IMHO, not enough to be considered Cray-style.
>>
>> That property is that the length of the vector register is chosen to
>> absorb the latency to memory. SMID is too short to have this property.
>>

> I don't like this definition at all.
> For starter, what is "memory"? Does L1D cache count, or only L2 and
> higher?

Those machines had no L1 or L2 (or LLC) caches. Consider the problems
for which they were designed--arrays as big as the memory (sometimes
bigger !!) and processed over and over again with numerical algorithms.
Caches would simply miss on each memory reference (ignoring TLB effects)
With the caches never supplying data to the calculations why have them
at all ??

> Then, what is "absorb" ?

Absorb means that the first data of a vector arrives and can start
calculation before the last address of the memory reference goes out.
This, in turn, means that one can create a continuous stream of
outbound addresses forever and thus cone can create a stream of
continuous calculations forever. {{Where 'forever' means thousands
of cycles but no where near the lifetime of the universe.}}

Now, obviously, this means the memory system has to be able to make
forward progress on all those memory accesses continuously.

> Is the whole VR register file part of
> absorbent or latency should be covered by one register?

A single register covers a single memory reference latency.

> Is OoO machinery
> part of absorbent?

The only OoO in the CRAYs was delivery of gather data back to the
vector register*. Scatter stores were sent out in order, as were the
addresses of the gather loads.

(*) bank conflicts would delay conflicting accesses but not those
of other banks, creating an OoO effect of returning data. This was
re-ordered back to IO prior to forwarding data into calculation.

> Is HW threading part of absorbent?

Absolutely not--none of the CRAYs did this--later XMPs and YMPs did
use lanes (SIMD with vector) but always did calculations in order
and always sent out addresses (and data when appropriate) in order.

> And for any of
> your possible answers I have my "Why?".

No harm in asking.

>> > In my book, the critical distinction is that at least one size of
>> > partial (chopped) none-load-store vector operations has higher
>> > throughput (and hopefully, but not necessarily lower latency) than
>> > full vector operations of the same type.

Tim Rentsch wrote:

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

>> Tim Rentsch wrote:
>>
>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>
>>>> If I really had to write a 64x64->128 MUL, with no widening MUL or
>>>> MULH which returns the high half, then I would punt and do it using
>>>> 32-bit parts (all variables are u64): [...]
>>>
>>> I wrote some code along the same lines. A difference is you
>>> are considering unsigned multiplication, and I am considering
>>> signed multiplication.
>>
>> Signed mul is just a special case of unsigned mul, right?
>>
>> I.e. in case of a signed widening mul, you'd first extract the signs,
>> convert the inputs to unsigned, then do the unsigned widening mul,
>> before finally resotirng the sign as the XOR of the input signs?
>>
>> There is a small gotcha if either of the inputs are of the 0x80000000
>> form, i.e. MININT, but the naive iabs() conversion will do the right
>> thing by leaving the input unchanged.
>>
>> At the other end there cannot be any issues since restoring a negative
>> output sign cannot overflow/fail.

> It isn't quite that simple. Some of what you describe has a risk
> of running afoul of implementation-defined behavior or undefined
> behavior (as for example abs( INT_MIN )). I'm pretty sure it's
> possible to avoid those pitfalls, but it requires a fair amount
> of care and careful thinking.

It would be supremely nice if we could go back in time before
computers and reserve an integer encoding that represents the
value of "there is no value here" and mandate if upon integer
arithmetic.

> Note that my goal is only to avoid the possibility of undefined
> behavior that comes from signed overflow. My approach is to safely
> determine whether the signed multiplication would overflow, and if
> it wouldn't then simply use signed arithmetic to get the result.

Double width multiplication cannot overflow. 2n = n×n then, ignoring
the top n bits gives you your non-overflowing multiply.

> I use unsigned types to determine the safety, and if it's safe then
> using signed types to get a result. For the current problem I don't
> care about widening, except as it might help to determine safety.

Thomas Koenig wrote:

> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>> Michael S <already5chosen@yahoo.com> writes:
>>>As discussed here just recently, there are good reason to avoid
>>>'unsigned' array indices in performance-oriented programs running under
>>>IL32P64 or I32LP64 C environments. Everything else is preferable -
>>>int, ptrdiff_t, size_t.
>>
>> If Fortran makes unsigned overflow illegal, Fortran compilers can
>> perform the same shenanigans for unsigned that C compilers do for
>> signed integers; so if signed int really is preferable because of
>> these shenanigans, unsigned with the same shenanigans would be
>> preferable, too.

> One problem is that, without 2^n modulo, something like a
> multiplicative hash would be illegal.

In HW we can reverse the bit order of the fields at zero cost making
hashes that "whiten" the data better.

> People would do it anyway, ignoring the prohibition, because it
> is so useful, and subsequent hilarity will ensue.