On Tuesday, October 12, 2021 at 8:48:06 AM UTC-6, MitchAlsup wrote:
> On Tuesday, October 12, 2021 at 8:39:58 AM UTC-5, David Brown wrote:

> > But do I take it that you agree with me that C is not a "high-level
> > assembly"?

> > A vital characteristic of assembly, as a programming language, is that
> > the generated code does /exactly/ what you order, no more and no less,
> > without re-ordering, optimising, removing or adding anything. C is not
> > a language remotely like that, never has been, never will be.

> You have obviously never used a good macro assembler............

Touché.

However, a macro assembler doesn't force you to _use_ any macros
in your code.

PL/360 is a high-level assembler. C is definitely not a "high-level
assembler" in that sense. However, since C can be used to reduce
the need for assembly language, referring to it as a "high-level
assembler" where one is talking loosely, and not bound to a
particular definition of the term, was not really a mistake, even if
it has turned out, in hindsight, to have led to some needless
confusion.

Recent changes in the C language... have reduced the ability to
use C instead of assembler partly because they've moved the
language further away from assembler language and further
towards more typical high-level languages. That fact isn't
changed by the set of definitions we use.

John Savard

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Saturday, October 16, 2021 at 9:52:18 AM UTC-5, Ivan Godard wrote:
>> On 10/16/2021 7:21 AM, Stephen Fuld wrote:
>> > On 10/16/2021 3:49 AM, Thomas Koenig wrote:
>> >> MitchAlsup <Mitch...@aol.com> schrieb:
>
>> >> Ideas? Comments?
>> >
>> > The run time cost of things like buffer overrun checking is reduced on
>> > modern OoO CPUs, as (assuming the compiler makes the information
>> > available) the checking can be done in parallel with the subsequent
>> > instructions, and only commit those instructions if the check passes.
>> > The same idea might help with the signed overflow problems.
><
> Real HW designers have been doing that since at least 1990............
><
>> Signed overflow does not require delayed check; it requires control of
>> delivery of the checked event. Not everything is vanilla C; there are
>> other languages with other rules, and even in C there are pragmas and
>> flags. So sometimes you should check and sometimes not, and you can't
>> afford control flow to decide.
><
> There was an argument in 16-bit machines, that became harder in 32-bit
> machine, that becomes indefensible in 64-bit machines:: not performing
> signed overflow/underflow checks.

The usual signed data types today have 8, 16, 32 or 64 bits.
Any of them can overflow on addition and multiplication,
and not all languages promote to "int" automatically
(Fortran, for example, does not, an 8-bit calculation will
be done in 8 bits there).

The case we have been discussing here is usually 32 bit signed
ints in 64 bit registers.

Are you advocating having signed overflow checks for each of the
data types above? Or just for 32 bit and 64 bit, or just 64 bit?

I think POWER has sticky overflow bits for 64 and 32 bit operations,
so there is something along these lines, but not for 8 or 16 bit.

Prescribing something to happen on overflow of less than word size
also restricts what the adder can look like, somewhat.

Quadibloc <jsavard@ecn.ab.ca> schrieb:
> On Tuesday, October 12, 2021 at 11:26:17 AM UTC-6, Stefan Monnier wrote:
>
>> I think the solution involves going carefully over every case of UB
>> and refining it (on a case-by-case basis) so it still provides the
>> freedom the compilers need while giving sufficient guarantees for the
>> programmers when they know the properties of their underlying system
>> (e.g. so they can write code which depends on a flat address space
>> without fearing the compiler).
>>
>> This is hard work and I'm not volunteering.
>
> I do not blame you for not volunteering for this task.
>
> But I think your characterization of it as "hard work" may be
> less than accurate.
>
> It certainly is possible to write a compiler for "old-fashioned" C
> that still has some optimization capabilities, enough to make it
> useful.

It will not be writing the compiler that will be hard, it is writing
and getting agreement on the specification for it (the sub-standard,
if you will).

On 10/21/2021 11:13 PM, Thomas Koenig wrote:
> MitchAlsup <MitchAlsup@aol.com> schrieb:
>> On Saturday, October 16, 2021 at 9:52:18 AM UTC-5, Ivan Godard wrote:
>>> On 10/16/2021 7:21 AM, Stephen Fuld wrote:
>>>> On 10/16/2021 3:49 AM, Thomas Koenig wrote:
>>>>> MitchAlsup <Mitch...@aol.com> schrieb:
>>
>>>>> Ideas? Comments?
>>>>
>>>> The run time cost of things like buffer overrun checking is reduced on
>>>> modern OoO CPUs, as (assuming the compiler makes the information
>>>> available) the checking can be done in parallel with the subsequent
>>>> instructions, and only commit those instructions if the check passes.
>>>> The same idea might help with the signed overflow problems.
>> <
>> Real HW designers have been doing that since at least 1990............
>> <
>>> Signed overflow does not require delayed check; it requires control of
>>> delivery of the checked event. Not everything is vanilla C; there are
>>> other languages with other rules, and even in C there are pragmas and
>>> flags. So sometimes you should check and sometimes not, and you can't
>>> afford control flow to decide.
>> <
>> There was an argument in 16-bit machines, that became harder in 32-bit
>> machine, that becomes indefensible in 64-bit machines:: not performing
>> signed overflow/underflow checks.
>
> The usual signed data types today have 8, 16, 32 or 64 bits.
> Any of them can overflow on addition and multiplication,
> and not all languages promote to "int" automatically
> (Fortran, for example, does not, an 8-bit calculation will
> be done in 8 bits there).
>
> The case we have been discussing here is usually 32 bit signed
> ints in 64 bit registers.
>
> Are you advocating having signed overflow checks for each of the
> data types above? Or just for 32 bit and 64 bit, or just 64 bit?
>
> I think POWER has sticky overflow bits for 64 and 32 bit operations,
> so there is something along these lines, but not for 8 or 16 bit.
>
> Prescribing something to happen on overflow of less than word size
> also restricts what the adder can look like, somewhat.
>

Consider also SIMD. If the data is 4X16 (for pixels, say) do yo check
each of the four lanes of a = b + c?

On 10/21/2021 6:34 PM, Quadibloc wrote:
> On Tuesday, October 12, 2021 at 11:26:17 AM UTC-6, Stefan Monnier wrote:
>
>> I think the solution involves going carefully over every case of UB
>> and refining it (on a case-by-case basis) so it still provides the
>> freedom the compilers need while giving sufficient guarantees for the
>> programmers when they know the properties of their underlying system
>> (e.g. so they can write code which depends on a flat address space
>> without fearing the compiler).
>>
>> This is hard work and I'm not volunteering.
>
> I do not blame you for not volunteering for this task.
>
> But I think your characterization of it as "hard work" may be
> less than accurate.
>
> It certainly is possible to write a compiler for "old-fashioned" C
> that still has some optimization capabilities, enough to make it
> useful. But I think it is clear that what the two camps in this
> particular conflict want are incompatible, and can only be
> resolved by having at the least a compiler switch, and at the
> most by having two separate languages.

There is also the solution invented by Mssr. Guillotin.

Ivan Godard wrote:
> On 10/21/2021 11:13 PM, Thomas Koenig wrote:
>> MitchAlsup <MitchAlsup@aol.com> schrieb:
>>> On Saturday, October 16, 2021 at 9:52:18 AM UTC-5, Ivan Godard wrote:
>>>> On 10/16/2021 7:21 AM, Stephen Fuld wrote:
>>>>> On 10/16/2021 3:49 AM, Thomas Koenig wrote:
>>>>>> MitchAlsup <Mitch...@aol.com> schrieb:
>>>
>>>>>> Ideas? Comments?
>>>>>
>>>>> The run time cost of things like buffer overrun checking is reduced on
>>>>> modern OoO CPUs, as (assuming the compiler makes the information
>>>>> available) the checking can be done in parallel with the subsequent
>>>>> instructions, and only commit those instructions if the check passes.
>>>>> The same idea might help with the signed overflow problems.
>>> <
>>> Real HW designers have been doing that since at least 1990............
>>> <
>>>> Signed overflow does not require delayed check; it requires control of
>>>> delivery of the checked event. Not everything is vanilla C; there are
>>>> other languages with other rules, and even in C there are pragmas and
>>>> flags. So sometimes you should check and sometimes not, and you can't
>>>> afford control flow to decide.
>>> <
>>> There was an argument in 16-bit machines, that became harder in 32-bit
>>> machine, that becomes indefensible in 64-bit machines:: not performing
>>> signed overflow/underflow checks.
>>
>> The usual signed data types today have 8, 16, 32 or 64 bits.
>> Any of them can overflow on addition and multiplication,
>> and not all languages promote to "int" automatically
>> (Fortran, for example, does not, an 8-bit calculation will
>> be done in 8 bits there).
>>
>> The case we have been discussing here is usually 32 bit signed
>> ints in 64 bit registers.
>>
>> Are you advocating having signed overflow checks for each of the
>> data types above? Or just for 32 bit and 64 bit, or just 64 bit?
>>
>> I think POWER has sticky overflow bits for 64 and 32 bit operations,
>> so there is something along these lines, but not for 8 or 16 bit.
>>
>> Prescribing something to happen on overflow of less than word size
>> also restricts what the adder can look like, somewhat.
>>
>
> Consider also SIMD. If the data is 4X16 (for pixels, say) do yo check
> each of the four lanes of a = b + c?

Yes.

The exception auxillary info could indicate one or more lanes affected.
But for floats there could be different exceptions on different lanes.
If its a scatter-gather load there could be multiple page faults.
Probably best to abort the operation and let the exception handler
single step each lane and determine each's specific problems.

On 10/22/2021 6:30 AM, EricP wrote:
> Ivan Godard wrote:
>> On 10/21/2021 11:13 PM, Thomas Koenig wrote:
>>> MitchAlsup <MitchAlsup@aol.com> schrieb:
>>>> On Saturday, October 16, 2021 at 9:52:18 AM UTC-5, Ivan Godard wrote:
>>>>> On 10/16/2021 7:21 AM, Stephen Fuld wrote:
>>>>>> On 10/16/2021 3:49 AM, Thomas Koenig wrote:
>>>>>>> MitchAlsup <Mitch...@aol.com> schrieb:
>>>>
>>>>>>> Ideas?  Comments?
>>>>>>
>>>>>> The run time cost of things like buffer overrun checking is
>>>>>> reduced on
>>>>>> modern OoO CPUs, as (assuming the compiler makes the information
>>>>>> available) the checking can be done in parallel with the subsequent
>>>>>> instructions, and only commit those instructions if the check passes.
>>>>>> The same idea might help with the signed overflow problems.
>>>> <
>>>> Real HW designers have been doing that since at least 1990............
>>>> <
>>>>> Signed overflow does not require delayed check; it requires control of
>>>>> delivery of the checked event. Not everything is vanilla C; there are
>>>>> other languages with other rules, and even in C there are pragmas and
>>>>> flags. So sometimes you should check and sometimes not, and you can't
>>>>> afford control flow to decide.
>>>> <
>>>> There was an argument in 16-bit machines, that became harder in 32-bit
>>>> machine, that becomes indefensible in 64-bit machines:: not performing
>>>> signed overflow/underflow checks.
>>>
>>> The usual signed data types today have 8, 16, 32 or 64 bits.
>>> Any of them can overflow on addition and multiplication,
>>> and not all languages promote to "int" automatically
>>> (Fortran, for example, does not, an 8-bit calculation will
>>> be done in 8 bits there).
>>>
>>> The case we have been discussing here is usually 32 bit signed
>>> ints in 64 bit registers.
>>>
>>> Are you advocating having signed overflow checks for each of the
>>> data types above?  Or just for 32 bit and 64 bit, or just 64 bit?
>>>
>>> I think POWER has sticky overflow bits for 64 and 32 bit operations,
>>> so there is something along these lines, but not for 8 or 16 bit.
>>>
>>> Prescribing something to happen on overflow of less than word size
>>> also restricts what the adder can look like, somewhat.
>>>
>>
>> Consider also SIMD. If the data is 4X16 (for pixels, say) do yo check
>> each of the four lanes of a = b + c?
>
> Yes.
>
> The exception auxillary info could indicate one or more lanes affected.
> But for floats there could be different exceptions on different lanes.
> If its a scatter-gather load there could be multiple page faults.
> Probably best to abort the operation and let the exception handler
> single step each lane and determine each's specific problems.

But there's another issue, in C at least: if scalar widens to int then
the single step might not fail - until the narrowing to put the result
back into the SIMD maybe.

IMO, preserving enough info to single step lanes would in practice
preclude must optimization and lose the gain from SIMD. The only
plausible compiler behavior would be to produce two copies of each
function, one SIMD and one scalar. And even then I wouldn't want to deal
with calls with SIMD arguments - you'd have to duplicate the whole call
tree back out to whatever one was only scalar.

I've never heard of any compiler doing this - can you relieve my ignorance?

Ivan Godard wrote:
> On 10/22/2021 6:30 AM, EricP wrote:
>> Ivan Godard wrote:
>>> On 10/21/2021 11:13 PM, Thomas Koenig wrote:
>>>> MitchAlsup <MitchAlsup@aol.com> schrieb:
>>>>> On Saturday, October 16, 2021 at 9:52:18 AM UTC-5, Ivan Godard wrote:
>>>>>> On 10/16/2021 7:21 AM, Stephen Fuld wrote:
>>>>>>> On 10/16/2021 3:49 AM, Thomas Koenig wrote:
>>>>>>>> MitchAlsup <Mitch...@aol.com> schrieb:
>>>>>
>>>>>>>> Ideas? Comments?
>>>>>>>
>>>>>>> The run time cost of things like buffer overrun checking is
>>>>>>> reduced on
>>>>>>> modern OoO CPUs, as (assuming the compiler makes the information
>>>>>>> available) the checking can be done in parallel with the subsequent
>>>>>>> instructions, and only commit those instructions if the check
>>>>>>> passes.
>>>>>>> The same idea might help with the signed overflow problems.
>>>>> <
>>>>> Real HW designers have been doing that since at least 1990............
>>>>> <
>>>>>> Signed overflow does not require delayed check; it requires
>>>>>> control of
>>>>>> delivery of the checked event. Not everything is vanilla C; there are
>>>>>> other languages with other rules, and even in C there are pragmas and
>>>>>> flags. So sometimes you should check and sometimes not, and you can't
>>>>>> afford control flow to decide.
>>>>> <
>>>>> There was an argument in 16-bit machines, that became harder in 32-bit
>>>>> machine, that becomes indefensible in 64-bit machines:: not performing
>>>>> signed overflow/underflow checks.
>>>>
>>>> The usual signed data types today have 8, 16, 32 or 64 bits.
>>>> Any of them can overflow on addition and multiplication,
>>>> and not all languages promote to "int" automatically
>>>> (Fortran, for example, does not, an 8-bit calculation will
>>>> be done in 8 bits there).
>>>>
>>>> The case we have been discussing here is usually 32 bit signed
>>>> ints in 64 bit registers.
>>>>
>>>> Are you advocating having signed overflow checks for each of the
>>>> data types above? Or just for 32 bit and 64 bit, or just 64 bit?
>>>>
>>>> I think POWER has sticky overflow bits for 64 and 32 bit operations,
>>>> so there is something along these lines, but not for 8 or 16 bit.
>>>>
>>>> Prescribing something to happen on overflow of less than word size
>>>> also restricts what the adder can look like, somewhat.
>>>>
>>>
>>> Consider also SIMD. If the data is 4X16 (for pixels, say) do yo check
>>> each of the four lanes of a = b + c?
>>
>> Yes.
>>
>> The exception auxillary info could indicate one or more lanes affected.
>> But for floats there could be different exceptions on different lanes.
>> If its a scatter-gather load there could be multiple page faults.
>> Probably best to abort the operation and let the exception handler
>> single step each lane and determine each's specific problems.
>
> But there's another issue, in C at least: if scalar widens to int then
> the single step might not fail - until the narrowing to put the result
> back into the SIMD maybe.
>
> IMO, preserving enough info to single step lanes would in practice
> preclude must optimization and lose the gain from SIMD. The only
> plausible compiler behavior would be to produce two copies of each
> function, one SIMD and one scalar. And even then I wouldn't want to deal
> with calls with SIMD arguments - you'd have to duplicate the whole call
> tree back out to whatever one was only scalar.
>
> I've never heard of any compiler doing this - can you relieve my ignorance?

I don't see the problem.
The exception handler gets the program counter of the aborted instruction,
reads and parses it, sees it is SIMD on some registers and emulates it
for lanes 0..N.

If the instruction is SIMD Add16 Trap Overflow on a 64-bit cpu then part
of that emulation is to compare the lane result to INT16_MIN..INT16_MAX
to determine lanes 1 and 3 overflowed.

This handler choses to saturate on overflow and continue, so it
substitutes the appropriate field values, increments PC and returns.

Ivan Godard <ivan@millcomputing.com> schrieb:
> On 10/21/2021 11:13 PM, Thomas Koenig wrote:

>> The usual signed data types today have 8, 16, 32 or 64 bits.
>> Any of them can overflow on addition and multiplication,
>> and not all languages promote to "int" automatically
>> (Fortran, for example, does not, an 8-bit calculation will
>> be done in 8 bits there).
>>
>> The case we have been discussing here is usually 32 bit signed
>> ints in 64 bit registers.
>>
>> Are you advocating having signed overflow checks for each of the
>> data types above? Or just for 32 bit and 64 bit, or just 64 bit?
>>
>> I think POWER has sticky overflow bits for 64 and 32 bit operations,
>> so there is something along these lines, but not for 8 or 16 bit.
>>
>> Prescribing something to happen on overflow of less than word size
>> also restricts what the adder can look like, somewhat.
>>
>
> Consider also SIMD. If the data is 4X16 (for pixels, say) do yo check
> each of the four lanes of a = b + c?

Maybe there is a case to be made for using -INT_MAX -1 as an signed
integer NaN.

I would be surprised if people had not tried this before.

On Friday, October 22, 2021 at 1:13:21 AM UTC-5, Thomas Koenig wrote:
> MitchAlsup <Mitch...@aol.com> schrieb:
> > On Saturday, October 16, 2021 at 9:52:18 AM UTC-5, Ivan Godard wrote:
> >> On 10/16/2021 7:21 AM, Stephen Fuld wrote:
> >> > On 10/16/2021 3:49 AM, Thomas Koenig wrote:
> >> >> MitchAlsup <Mitch...@aol.com> schrieb:
> >
> >> >> Ideas? Comments?
> >> >
> >> > The run time cost of things like buffer overrun checking is reduced on
> >> > modern OoO CPUs, as (assuming the compiler makes the information
> >> > available) the checking can be done in parallel with the subsequent
> >> > instructions, and only commit those instructions if the check passes.
> >> > The same idea might help with the signed overflow problems.
> ><
> > Real HW designers have been doing that since at least 1990............
> ><
> >> Signed overflow does not require delayed check; it requires control of
> >> delivery of the checked event. Not everything is vanilla C; there are
> >> other languages with other rules, and even in C there are pragmas and
> >> flags. So sometimes you should check and sometimes not, and you can't
> >> afford control flow to decide.
> ><
> > There was an argument in 16-bit machines, that became harder in 32-bit
> > machine, that becomes indefensible in 64-bit machines:: not performing
> > signed overflow/underflow checks.
<
> The usual signed data types today have 8, 16, 32 or 64 bits.
> Any of them can overflow on addition and multiplication, (* for later)
> and not all languages promote to "int" automatically
> (Fortran, for example, does not, an 8-bit calculation will
> be done in 8 bits there).
>
> The case we have been discussing here is usually 32 bit signed
> ints in 64 bit registers.
>
> Are you advocating having signed overflow checks for each of the
> data types above? Or just for 32 bit and 64 bit, or just 64 bit?
<
My 66000 has arithmetic on signed numbers that raise OVERFLOW.
My 66000 has a signed extract instruction that detects significance
above the width of the container.
<
So the 64-bit case has no overhead, and the smaller container cases
use the extract instruction to smash the data back into the proper
size (checked.)
>
> I think POWER has sticky overflow bits for 64 and 32 bit operations,
> so there is something along these lines, but not for 8 or 16 bit.
>
> Prescribing something to happen on overflow of less than word size
> also restricts what the adder can look like, somewhat.
<
Which is why I don't do it there.
<
My solution works for all data sizes smaller than 64-bits {63,62,...2,1}
In this respect, there is nothing magical about 8-bits that is not similarly
magical about 7-bits or 9-bits.
<
With I32PL64 LLVM generates those extract instructions.
<
(* for later)
There are also bit fields, which should be given the exact same standards
of arithmetic sanity !! A 12-bit field should overflow in the same way an 8-bit
or 16-bit field overflows.
<
So, My 66000, can multiply a 13-bit field by a 34-bit field and store the
result in a 18-bit container, and get 18-bit signed overflow just like non-mis-
matched arithmetic sizes. {It takes one instruction more, but "you" get to
pick between sanity and speed.}

On Friday, October 22, 2021 at 5:19:19 AM UTC-5, Ivan Godard wrote:
> On 10/21/2021 11:13 PM, Thomas Koenig wrote:
> > MitchAlsup <Mitch...@aol.com> schrieb:

> >
> > The usual signed data types today have 8, 16, 32 or 64 bits.
> > Any of them can overflow on addition and multiplication,
> > and not all languages promote to "int" automatically
> > (Fortran, for example, does not, an 8-bit calculation will
> > be done in 8 bits there).
> >
> > The case we have been discussing here is usually 32 bit signed
> > ints in 64 bit registers.
> >
> > Are you advocating having signed overflow checks for each of the
> > data types above? Or just for 32 bit and 64 bit, or just 64 bit?
> >
> > I think POWER has sticky overflow bits for 64 and 32 bit operations,
> > so there is something along these lines, but not for 8 or 16 bit.
> >
> > Prescribing something to happen on overflow of less than word size
> > also restricts what the adder can look like, somewhat.
> >
> Consider also SIMD. If the data is 4X16 (for pixels, say) do yo check
> each of the four lanes of a = b + c?
<
Arithmetic is either sane or insane.
<
I would pick sanity.
<
Others may choose to pick speed, and they get what they deserve.

On Friday, October 22, 2021 at 10:59:49 AM UTC-5, Thomas Koenig wrote:
> Ivan Godard <iv...@millcomputing.com> schrieb:
> > On 10/21/2021 11:13 PM, Thomas Koenig wrote:
>
> >> The usual signed data types today have 8, 16, 32 or 64 bits.
> >> Any of them can overflow on addition and multiplication,
> >> and not all languages promote to "int" automatically
> >> (Fortran, for example, does not, an 8-bit calculation will
> >> be done in 8 bits there).
> >>
> >> The case we have been discussing here is usually 32 bit signed
> >> ints in 64 bit registers.
> >>
> >> Are you advocating having signed overflow checks for each of the
> >> data types above? Or just for 32 bit and 64 bit, or just 64 bit?
> >>
> >> I think POWER has sticky overflow bits for 64 and 32 bit operations,
> >> so there is something along these lines, but not for 8 or 16 bit.
> >>
> >> Prescribing something to happen on overflow of less than word size
> >> also restricts what the adder can look like, somewhat.
> >>
> >
> > Consider also SIMD. If the data is 4X16 (for pixels, say) do yo check
> > each of the four lanes of a = b + c?
> Maybe there is a case to be made for using -INT_MAX -1 as an signed
> integer NaN.
>
> I would be surprised if people had not tried this before.
<
The CMP instruction in My 66000 has a test for SNEGMAX (same number as
above) SPOSMAX, and UPOSMAX so you don't even need a constant in order
to perform the compare.

MitchAlsup wrote:
> On Friday, October 22, 2021 at 1:13:21 AM UTC-5, Thomas Koenig wrote:
>> MitchAlsup <Mitch...@aol.com> schrieb:
>>> On Saturday, October 16, 2021 at 9:52:18 AM UTC-5, Ivan Godard wrote:
>>>> On 10/16/2021 7:21 AM, Stephen Fuld wrote:
>>>>> On 10/16/2021 3:49 AM, Thomas Koenig wrote:
>>>>>> MitchAlsup <Mitch...@aol.com> schrieb:
>>>>>> Ideas? Comments?
>>>>> The run time cost of things like buffer overrun checking is reduced on
>>>>> modern OoO CPUs, as (assuming the compiler makes the information
>>>>> available) the checking can be done in parallel with the subsequent
>>>>> instructions, and only commit those instructions if the check passes.
>>>>> The same idea might help with the signed overflow problems.
>>> <
>>> Real HW designers have been doing that since at least 1990............
>>> <
>>>> Signed overflow does not require delayed check; it requires control of
>>>> delivery of the checked event. Not everything is vanilla C; there are
>>>> other languages with other rules, and even in C there are pragmas and
>>>> flags. So sometimes you should check and sometimes not, and you can't
>>>> afford control flow to decide.
>>> <
>>> There was an argument in 16-bit machines, that became harder in 32-bit
>>> machine, that becomes indefensible in 64-bit machines:: not performing
>>> signed overflow/underflow checks.
> <
>> The usual signed data types today have 8, 16, 32 or 64 bits.
>> Any of them can overflow on addition and multiplication, (* for later)
>> and not all languages promote to "int" automatically
>> (Fortran, for example, does not, an 8-bit calculation will
>> be done in 8 bits there).
>>
>> The case we have been discussing here is usually 32 bit signed
>> ints in 64 bit registers.
>>
>> Are you advocating having signed overflow checks for each of the
>> data types above? Or just for 32 bit and 64 bit, or just 64 bit?
> <
> My 66000 has arithmetic on signed numbers that raise OVERFLOW.
> My 66000 has a signed extract instruction that detects significance
> above the width of the container.
> <
> So the 64-bit case has no overhead, and the smaller container cases
> use the extract instruction to smash the data back into the proper
> size (checked.)
>> I think POWER has sticky overflow bits for 64 and 32 bit operations,
>> so there is something along these lines, but not for 8 or 16 bit.
>>
>> Prescribing something to happen on overflow of less than word size
>> also restricts what the adder can look like, somewhat.
> <
> Which is why I don't do it there.
> <
> My solution works for all data sizes smaller than 64-bits {63,62,...2,1}
> In this respect, there is nothing magical about 8-bits that is not similarly
> magical about 7-bits or 9-bits.
> <
> With I32PL64 LLVM generates those extract instructions.
> <
> (* for later)
> There are also bit fields, which should be given the exact same standards
> of arithmetic sanity !! A 12-bit field should overflow in the same way an 8-bit
> or 16-bit field overflows.
> <
> So, My 66000, can multiply a 13-bit field by a 34-bit field and store the
> result in a 18-bit container, and get 18-bit signed overflow just like non-mis-
> matched arithmetic sizes. {It takes one instruction more, but "you" get to
> pick between sanity and speed.}

I'd also have traps for signed and unsigned converts to powers of 2.
Compare And Trap instructions handle the non-power-2 cases
for bounds and subtype range checks.

As I mentioned in an earlier post, these trap checks can be Spectre
susceptible so I'd have two forms, both synchronous and asynchronous.
Synchronous copies the checked value creating a write dependency
which can be used to stall dependents if the check fails.

If I was supporting saturate arithmetic I'd want similar but
saturating to powers of 2.

I've never heard of a non power of 2 saturate arithmetic. But if
there is such a thing then signed and unsigned Compare And Sat too.

Le 16/10/2021 à 16:21, Stephen Fuld a écrit :
> The run time cost of things like buffer overrun checking is reduced on
> modern OoO CPUs, as (assuming the compiler makes the information
> available) the checking can be done in parallel with the subsequent
> instructions, and only commit those instructions if the check passes.

Well yeah, but it always has a cost nevertheless. Because it's always at
the expense of potentially something else being done in parallel.

That said, in many actual cases, out-of-bounds checks can be done on a
whole block once rather than on each individual item access while not
losing security, as in many cases, accesses are just increments and not
just fully random.

On 2021-10-22, MitchAlsup <MitchAlsup@aol.com> wrote:
> On Friday, October 22, 2021 at 10:59:49 AM UTC-5, Thomas Koenig wrote:
>> Ivan Godard <iv...@millcomputing.com> schrieb:
>> > On 10/21/2021 11:13 PM, Thomas Koenig wrote:
>>
>> >> The usual signed data types today have 8, 16, 32 or 64 bits.
>> >> Any of them can overflow on addition and multiplication,
>> >> and not all languages promote to "int" automatically
>> >> (Fortran, for example, does not, an 8-bit calculation will
>> >> be done in 8 bits there).
>> >>
>> >> The case we have been discussing here is usually 32 bit signed
>> >> ints in 64 bit registers.
>> >>
>> >> Are you advocating having signed overflow checks for each of the
>> >> data types above? Or just for 32 bit and 64 bit, or just 64 bit?
>> >>
>> >> I think POWER has sticky overflow bits for 64 and 32 bit operations,
>> >> so there is something along these lines, but not for 8 or 16 bit.
>> >>
>> >> Prescribing something to happen on overflow of less than word size
>> >> also restricts what the adder can look like, somewhat.
>> >>
>> >
>> > Consider also SIMD. If the data is 4X16 (for pixels, say) do yo check
>> > each of the four lanes of a = b + c?
>> Maybe there is a case to be made for using -INT_MAX -1 as an signed
>> integer NaN.
>>
>> I would be surprised if people had not tried this before.
><
> The CMP instruction in My 66000 has a test for SNEGMAX (same number as
> above) SPOSMAX, and UPOSMAX so you don't even need a constant in order
> to perform the compare.
+100!

--

7-77-777
Evil Sinner!
with software, you repeat same experiment, expecting different results...

On 2021-10-22, Guillaume <message@bottle.org> wrote:
> Le 16/10/2021 à 16:21, Stephen Fuld a écrit :
>> The run time cost of things like buffer overrun checking is reduced on
>> modern OoO CPUs, as (assuming the compiler makes the information
>> available) the checking can be done in parallel with the subsequent
>> instructions, and only commit those instructions if the check passes.
>
> Well yeah, but it always has a cost nevertheless. Because it's always at
> the expense of potentially something else being done in parallel.
>
> That said, in many actual cases, out-of-bounds checks can be done on a
> whole block once rather than on each individual item access while not
> losing security, as in many cases, accesses are just increments and not
> just fully random.
Well, if sequential access, you just check only once, if upper bound exceeds
array limit...

--

7-77-777
Evil Sinner!
with software, you repeat same experiment, expecting different results...

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> On 2021-10-21 15:39, Tim Rentsch wrote:
>
>> I believe it is the case that none of these properties [of the Ada
>> type system] addresses the matter of differentiating (as one
>> example)
>> wrapping signed operations versus saturating signed operations.
>> AFAICT the Ada type system doesn't help in any significant way in
>> addressing this issue.
>
> Ada has two kinds of built-in integer types: signed integer types
> and modular integer types.
>
> While a signed integer type can be constrained to a non-negative
> range by subtyping, it still uses signed integer operations and
> representations, and the results of expressions can be negative.
> The range is checked only when a value is assigned to a variable of
> the subtype, or passed as a parameter of the subtype, or in other
> similar subtype-constrained contexts.

My impression is that signed integer operations (for the usual
arithmetic operators, and perhaps a few other) in Ada are defined
to produce exact results, of whatever size, and only when an
expression is assigned or used as an argument is the range
checked against the intended target. Is that right? In any
case thank you for the explanation. Assuming my impression is
accurate, I like the Ada model for how integer arithmetic works.

> Signed integer overflow or underflow are required to raise the
> Constraint_Error exception. There are no built-in options for
> signed wrap-around or saturation, but one can of course define one's
> own types with such operations overloading "+", "-" etc.)

A large topic, and one which I hope to address separately.

> [..other kinds of integer types..]
>
> For the point under discussion, it seems to me that the main
> difference between C and Ada is that signed overflow is undefined
> behaviour in the C standard, but in Ada is required to raise an
> exception.

Note that what C calls undefined behavior is not a single
semantic but rather a range of possible allowed semantics. A C
implementation could choose to define the behavior of signed
integer overflow so that it would match how Ada works. The main
point of my suggestion upthread is to put the choice of how
signed integer overflow works back in the hands of the developer,
rathern than abdicating and letting the implementor pick
(especially since many of them seem to decide so badly). We
could (and I think should) add to the list of standard pragmas
this one:

#pragma STDC SIGNED_OVERFLOW LIKE_Ada

probably with some description of how C might handle its analog
of Constraint_Error exceptions.

On Friday, October 22, 2021 at 12:14:57 AM UTC-6, Thomas Koenig wrote:

> It will not be writing the compiler that will be hard, it is writing
> and getting agreement on the specification for it (the sub-standard,
> if you will).

The point of my post, however, was not that the work would not be
hard, but rather that it would be even harder: to wit, impossible.

The goals of the two groups involved are in direct conflict, rather than
there being a way to find a standard that satisfies both.

John Savard

On Friday, October 22, 2021 at 4:22:53 AM UTC-6, Ivan Godard wrote:

> There is also the solution invented by Mssr. Guillotin.

That isn't a solution. If the problem is to satisfy both sides,
killing the branch of the language that satisfies one of them
constitutes failure; one side is not satisfied.

However, reality is more complex than that. The reality is
that C99 and gcc are viewed by the dissatisfied side as
just that "solution" as having happened already...

and nothing is preventing them from taking the last version
of gcc they liked, and maintaining it themselves. They could
even issue a language standard for a language which they
could call CC (for "Classic C") or something.

My first thought was KRC, but that runs the risk of real
individuals objecting to being associated with a
retrogade movement.

John Savard

On Friday, October 22, 2021 at 9:59:49 AM UTC-6, Thomas Koenig wrote:

> Maybe there is a case to be made for using -INT_MAX -1 as an signed
> integer NaN.

> I would be surprised if people had not tried this before.

I wouldn't be, since they could have tried something equivalent
instead back when people were trying such bold options.

That is: while what you suggest would add extra complexity to
an ALU intended for operating on quantities represented in
two's complement notation, alternative integer representations
already have the needed complications present, thus allowing
making... *minus zero*... into a signed integer NaN to be
done "for free".

So I think _that_ might have been tried, for either one's complement
or sign-magnitude machines... eliminating the need to try the
equivalent you suggest in two's complement.

John Savard

On Friday, October 22, 2021 at 11:00:30 AM UTC-6, MitchAlsup wrote:

> Arithmetic is either sane or insane.

> I would pick sanity.

> Others may choose to pick speed, and they get what they deserve.

Since speed is what is _going_ to get picked, one has to figure out
a way to get sanity when needed with minimal overhead in machines
designed around speed.

Or, even better, if possible, a way to get sanity "for free" so that sanity
has a chance to get implemented.

Unrealistic optimism (about human behavior) is as much not a way
to get effective results as unrealistic optimism (about the capabilities
of digital arithmetic units). That's what makes this issue a persistent
problem.

So one has to accept that sanity is likely to have a cost, and thus to
seek to find ways to minimize that cost, and to allow applications
for which the cost is willingly paid to coexist with applications not
prepared to pay the cost.

John Savard

EricP <ThatWouldBeTelling@thevillage.com> writes:

> Ivan Godard wrote:
>
>> On 10/19/2021 11:58 AM, Thomas Koenig wrote:
>>
>>> David Brown <david.brown@hesbynett.no> schrieb:
>>>
>>>> There are more problems than that. Consider "y = x + 3 - 2;".
>>>> (Imagine it is the result of a set of macros, or inline functions
>>>> and constant propagation, rather than a hand-written expression.)
>>>> Can a compiler change that to "y = x + 1;" with overflow checking
>>>> there? Does it need to do two operations, checking twice?
>>>
>>> In Fortran, it could according to the language definition, as
>>> long as parenthethes are kept. The language even allows to
>>> change (x - x) into zero for floats, never mind NaNs.
>>>
>>> Few compilers dare to implement that.
>>>
>>> It would be illegal for y = (x + 3) - 2.
>>
>> That rule has always bothered me for a language with operator
>> precedence. OP forces parens to resolve precedence: Fortran
>> (b+c)*a is not the same as b+c*a, although it is in APL where
>> there is no precedence. Don't you find that precedence parens
>> masquerading as optimization-control parens sometimes engender
>> bad code?
>
> It provides an easy mechanism for programmer to pass intent to a
> compiler. Historically mostly useful for floating point, but
> could be used for overflow and saturating integers too.
>
> It wouldn't work well as a default behavior in C because macros
> use so many parens.
>
> Do you have an alternative idea of how to succinctly instruct
> that this expression precedence must be interpreted as given?
> One could add a reserved word to a language like "exact
> (expression)" but that would get tedious if you were writing
> hundreds of thousands or millions of lines of weather or black
> hole simulations.

A few reactions.

Using a single notational construct to simultaneously express two
distinct kinds of constraints is inherently wrong.

Using parentheses compounds the problem. They are easy to
overlook, easy to forget the significance of, may imply
consequences that are not desired, and may confuse intent
in some uses.

The underlying tacit assumption has things backwards. The
default should be "do just what I say", with an explicit
indicator for when sloppy rearrangement is allowed. (The word
"sloppy" here means programmatically sloppy, not necessarily
mathematically sloppy.) A 'SLOPPY{ ... }' construct could
surround an expression, a statement, a set of statements, or an
entire block. An important lesson from C and aliasing rules is
that the default (so-called "strict aliasing") is wrong. What
works much better is 'restrict' - the compiler must allow for the
possibility of aliasing unless the developer explicitly indicates
that isn't necessary, in which case the burden of the guarantee
being right is on the developer, not the compiler. So it should
be with unsafe expression rearrangement.

> The upcoming new Ada standard, Ada 2022, adds standard libraries for
> big-number arithmetic, both integer and real.

Nitpick: you probably mean rationals or floating point, since reals are
pretty hard to implement in a computer.

Stefan

>> [actually, for a 32bit build, Emacs's limit is 512MB files], and Emacs
>> users just refrained from using Emacs to view or edit such large files
>> (tho some users developed workarounds such as `vlf.el` which lets you
>> view a chunk of the file).
> It sounds like it is trying to map whole files rather than
> managing moving windows onto mapped files or buffered IO.

By and large Emacs only ever does "read a whole file into memory" and
"write a whole file to disk". No `map`ping of any sort.

Stefan

On 2021-10-23 16:36, Tim Rentsch wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>
>> On 2021-10-21 15:39, Tim Rentsch wrote:
>>
>>> I believe it is the case that none of these properties [of the Ada
>>> type system] addresses the matter of differentiating (as one
>>> example)
>>> wrapping signed operations versus saturating signed operations.
>>> AFAICT the Ada type system doesn't help in any significant way in
>>> addressing this issue.
>>
>> Ada has two kinds of built-in integer types: signed integer types
>> and modular integer types.
>>
>> While a signed integer type can be constrained to a non-negative
>> range by subtyping, it still uses signed integer operations and
>> representations, and the results of expressions can be negative.
>> The range is checked only when a value is assigned to a variable of
>> the subtype, or passed as a parameter of the subtype, or in other
>> similar subtype-constrained contexts.
>
> My impression is that signed integer operations (for the usual
> arithmetic operators, and perhaps a few other) in Ada are defined
> to produce exact results, of whatever size, and only when an
> expression is assigned or used as an argument is the range
> checked against the intended target. Is that right?

No, if by "size" you mean the number of bits needed to represent the
number. Run-time integer operations in Ada work as in any traditional
compiled language: they use the HW operations, which usually generate
n-bit results from n-bit operands, with overflow possible.

Unbounded-size integer computations happen only at compile time (for
static expressions of "universal integer" type) or (in the upcoming Ada
2022 standard) when invoking the new Big_Numbers library packages.

That said, I believe an Ada compiler is permitted to compute with wider
intermediate results, for example to compute with 64-bit integers even
if the input operands and the result variable are 16-bit integers. That
could avoid overflow (and overflow exceptions) sometimes, but there
would be a check that the final result fits in 16 bits and in the
possibly narrower range of the subtype of the result variable.