Stefan Monnier <monnier@iro.umontreal.ca> schrieb:
>> satd.c: In function 'SATD':
>> satd.c:7:28: warning: iteration 15 invokes undefined behavior [-Waggressive-loop-optimizations]
>> 7 | for (dd=d[k=0]; k<16; dd=d[++k]) {
>
> The warning is pretty funny: the "[-W...]" part seems to say that this
> warns about places where GCC applies "aggressive optimizations", which
> in turn suggests that has optimizations that target code which GCC
> considers broken enough to warrant a warning.

Sounds like it.

> Since when do we care about the speed of broken code?

I don't think this is it. It is rather that aggressive loop
optimizations tend to actually break code that is broken as per the
language standard, so it is a good idea to warn the user about it.

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>>
>>> The major downside is that the world has adapted to the unwise
>>> decision to go I32LP64 for ~30 years, so any change now incurs
>>> significant switching cost.
>>
>>You don't care about cache or memory bandwidth, then?
>
> When that plays a role, I use the appropriate in-memory
> representation.

You may not do so, but people still use unadorned "int" or "usigned
int" in the reasonable expectation that it will give them good code.
With your suggestion, this would often not happen due to memory
congestion.

On 5/20/2021 9:10 AM, MitchAlsup wrote:
> On Wednesday, May 19, 2021 at 11:28:46 PM UTC-5, Stephen Fuld wrote:
>> On 5/19/2021 9:32 AM, Thomas Koenig wrote:
>>> EricP <ThatWould...@thevillage.com> schrieb:
>>>> MitchAlsup wrote:
>>>>> On Wednesday, May 19, 2021 at 7:23:04 AM UTC-5, Anton Ertl wrote:
>>>>>> Thomas Koenig <tko...@netcologne.de> writes:
>>>>>>> Anton Ertl <an...@mips.complang.tuwien.ac.at> schrieb:
>>>>>>>> Thomas Koenig <tko...@netcologne.de> writes:
>>>>>>>>> Unsigned loops can cause a headache, because it is often
>>>>>>>>> not possible to prove they actually terminate...
>>>>>>>> And the difference to signed loops is? Note that you wrote
>>>>>>>> "actually", so pretending that signed overflow does not happen does
>>>>>>>> not count.
>>>>>>> According to many language definitions, it does indeed not
>>>>>>> count.
>>>>>> This sentence makes no sense.
>>>>> <
>>>>> How about this::
>>>>> <
>>>>> Languages, that want to be ported across multiple architectures, and
>>>>> have high performing implementations, cannot specify that signed integers
>>>>> overflow.
>>>>> <
>>>>
>>>> The language spec should:
>>>> - allow the programmer to choose between bounds-range checked,
>>>> unchecked, modulo, or saturating data types
>>>
>>> That is not going to fly for an established, general-purpose
>>> language.
> <
>> A counter example is Ada, which implements most of those things.
> <
> And ADA has taken over what corner of programming/programmers ?

I didn't take popularity, much less "taken over", as a criterion (Ada is
certainly established and general purpose), but since you asked . . .

I understand Ada is popular for some high reliability high end embedded
systems such as in aeronautics, etc. According to Tiobe, (FWIW) Ada is
number 25 with a little over half a percent usage. By way of contrast,
C, the number one language is at about 13.5 percent. So Ada is small
(at about 4% of C's usage), but not insignificant (YMMV).

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On 5/20/2021 9:34 AM, MitchAlsup wrote:
> On Thursday, May 20, 2021 at 10:08:32 AM UTC-5, Stephen Fuld wrote:
>> On 5/19/2021 11:40 PM, Niklas Holsti wrote:
>>> On 2021-05-20 3:40, Stephen Fuld wrote:
>>>> On 5/19/2021 8:47 AM, EricP wrote:
>
>> Fair enough. This sort of gets back to the question of whether to add a
>> feature like this as an attribute of the variable (e.g. range) or of the
>> operation (e.g. bignum). I think there are arguments for each.
>>
>> BTW, I am unsure of what the requirement is here. Suppose you have a
>> variable with a range of 10-90. Do you want saturation at 90? That is
> <
> If the value to be written is outside of the range [10..90] you raise an
> exception. The raised exception decides what to do.

Certainly true for the non-saturating case, and is what Ada does. My
question is if you define saturating variables, what to do if you
somehow define the variable with a range *and* saturating.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

MitchAlsup <MitchAlsup@aol.com> writes:
>On Thursday, May 20, 2021 at 7:58:24 AM UTC-5, Terje Mathisen wrote:
>> Pretty much all large 32-bit programs needed to handle near-maximum
>> memory pools (i.e. ~3GB), and that meant doing it right with 32-bit ops,
>> since using 64-bit would be far slower.
><
>We should have made the transition to 64-bit machines (what) nearly 2
>decades ago ? 2003

I did. And yet I use a 32-bit program that falls over when its RAM
usage approaches 2GB (on a 16GB machine). Software has a long life.

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

On 2021-05-20, David Brown wrote:
> On 20/05/2021 13:45, Marcus wrote:
>> Den 2021-05-20 kl. 09:11, skrev David Brown:
>>> On 20/05/2021 04:12, MitchAlsup wrote:
>>>> On Wednesday, May 19, 2021 at 7:37:33 PM UTC-5, David Brown wrote:
>>>>> On 20/05/2021 01:54, MitchAlsup wrote:
>>>>>> On Wednesday, May 19, 2021 at 6:25:20 PM UTC-5, David Brown wrote:
>>>>>>> On 20/05/2021 00:11, Anton Ertl wrote:
>>>>>>>> David Brown <david...@hesbynett.no> writes:
>>>>>
>>>>>>>
>>>>>>> Perhaps it should also give the suggestion "you should be using
>>>>>>> unsigned
>>>>>>> types for this kind of thing". As a general rule, anything involving
>>>>>>> bit patterns should be unsigned types - signed types are for abstract
>>>>>>> numbers only.
>>>>>> <
>>>>>> All integral container that do not explicitly need to contain negative
>>>>>> numbers should be unsigned.
>>>>> That also works.
>>>>>
>>>>> But if you are saying this because overflow is defined for unsigned
>>>>> types in C, then I would disagree with the point - as overflow is
>>>>> generally (but not always) a mistake, whether signed or unsigned, and
>>>>> should not occur in normal code.
>>>> <
>>>> I am saying this because; unsigned arithmetic is much better defined
>>>> than signed arithmetic in C. The surprise coefficient is way lower.
>>>> <
>>>
>>> Yes, that's what I thought.  I disagree.  When I use types for
>>> arithmetic (outside of occasional very special cases, and bugs in my
>>> code), the arithmetic does not overflow.  Overflows are errors.  It
>>> doesn't matter what the language says - if I have 4294967295 apples in a
>>> pile, put another apple on, and you tell me I now have 0 apples, it is
>>> all nonsense.
>>>
>>> So IMHO correctly written arithmetic code does not overflow.  No
>>> overflow, no surprises.
>>>
>>> It's fine to use unsigned types for data that is naturally non-negative.
>>>   It makes sense to the reader.  And sometimes the extra bit of range is
>>> useful.
>>>
>>> But if you think unsigned types are better for general purpose numbers
>>> because they are "better defined", you are using the wrong types for the
>>> arithmetic you are doing, or you have failed to check your values before
>>> using them.
>>>
>>> I lost my appetite decades ago for smart-arse code that relies on
>>> overflows to see the end of a loop and that kind of thing.  I write my
>>> code to make sense - it says what it does, and does what it says,
>>> instead of playing "bit twiddling tricks".  Usually the result is not
>>> only simpler and clearer, safer and more portable, but is at least as
>>> efficient.  In the extremely few cases where you need to do something
>>> odd to squeeze the last clock cycle out of critical code, then you put
>>> in the extra "unsigned" casts and other ugly details.
>>>
>>
>> For some time now I have been in the camp that prefers signed integers
>> over unsigned integers for general arithmetic operations.
>>
>> I think that for most situations where you need to use numbers for
>> arithmetic operations, it is wise to use a type that can represent
>> negative numbers (e.g. to support various combinations of subtractions
>> and lt/gt comparisons without surprises).
>>
>> OTOH, for bitwise operations (and/or/shift/...), I prefer unsigned
>> integers. I think of "unsigned integer" as "bit vector".
>
> Agreed.
>
>>
>> That extra bit of range that you get with unsigned integers is usually
>> just a fallacy: if you need it, you're so close to the limit that you
>> should probably just double the integer size instead (e.g. go from
>> int32_t to int64_t).
>
> I work with microcontrollers, so that extra bit is often needed to
> correctly interact with hardware registers. But I agree that it is rare
> in normal usage to have a need to store numbers bigger than about 2
> billion but never need to go above around 4 billion.

I would think that if you're dealing with HW registers, you're probably
more in the domain of "bit vectors" than "numbers". At least that's my
experience (e.g. in my MC1 computer all memory mapped registers are
treated as uint32_t).

>
>>
>> Finally, I really don't like type-casting back and forth between
>> different integer types (not explicitly nor implicitly), so I tend
>> to use a single type as far as possible - and that usually happens to
>> be signed integers.
>>
>
> It is always nicest when you don't need conversions - but getting code
> correct is more important than getting it nice!

....which is why I like to avoid conversions. A common source of
errors is implicit type conversions in C, for instance. In my experience
a too rich mix of integer types is a sign of a poor design. Of course,
use the correct type for each situation, but try to use a limited and
well defined set of types in your interfaces, and try to limit the
number of types in each "domain".

> (Nitpick on the terminology, if you are interested - in C, there is no
> such thing as "typecasting". That's something that happens to actors in
> film and theatre. What you are talking about is /conversions/.
> Implicit conversions happen at assignment, in expressions, and function
> calls. Explicit conversions - such as "(uint64_t) x" - are called
> "casts". If you are not interested, that's okay - it's obvious what you
> meant.)
>

On 20 May 2021, MitchAlsup wrote
(in article<ec6f372d-d575-4cca-a595-65b81fe868e9n@googlegroups.com>):

> On Wednesday, May 19, 2021 at 11:28:46 PM UTC-5, Stephen Fuld wrote:
> > On 5/19/2021 9:32 AM, Thomas Koenig wrote:
> > > EricP <ThatWould...@thevillage.com> schrieb:
> > > > MitchAlsup wrote:
> > > > > On Wednesday, May 19, 2021 at 7:23:04 AM UTC-5, Anton Ertl wrote:
> > > > > > Thomas Koenig <tko...@netcologne.de> writes:
> > > > > > > Anton Ertl<an...@mips.complang.tuwien.ac.at> schrieb:
> > > > > > > > Thomas Koenig <tko...@netcologne.de> writes:
> > > > > > > > > Unsigned loops can cause a headache, because it is often
> > > > > > > > > not possible to prove they actually terminate...
> > > > > > > > And the difference to signed loops is? Note that you wrote
> > > > > > > > "actually", so pretending that signed overflow does not happen does
> > > > > > > > not count.
> > > > > > > According to many language definitions, it does indeed not
> > > > > > > count.
> > > > > > This sentence makes no sense.
> > > > > <
> > > > > How about this::
> > > > > <
> > > > > Languages, that want to be ported across multiple architectures, and
> > > > > have high performing implementations, cannot specify that signed integers
> > > > > overflow.
> > > > > <
> > > >
> > > > The language spec should:
> > > > - allow the programmer to choose between bounds-range checked,
> > > > unchecked, modulo, or saturating data types
> > >
> > > That is not going to fly for an established, general-purpose
> > > language.
> <
> > A counter example is Ada, which implements most of those things.
> <
> And ADA has taken over what corner of programming/programmers ?

The corner where getting the right result is the most important criterion.

--
Bill Findlay

On 20/05/2021 18:24, MitchAlsup wrote:
> On Thursday, May 20, 2021 at 2:11:23 AM UTC-5, David Brown wrote:
>> On 20/05/2021 04:12, MitchAlsup wrote:
>>> On Wednesday, May 19, 2021 at 7:37:33 PM UTC-5, David Brown wrote:
>>>> On 20/05/2021 01:54, MitchAlsup wrote:
>>>>> On Wednesday, May 19, 2021 at 6:25:20 PM UTC-5, David Brown wrote:
>>>>>> On 20/05/2021 00:11, Anton Ertl wrote:
>>>>>>> David Brown <david...@hesbynett.no> writes:
>>>>
>>>>>>
>>>>>> Perhaps it should also give the suggestion "you should be using unsigned
>>>>>> types for this kind of thing". As a general rule, anything involving
>>>>>> bit patterns should be unsigned types - signed types are for abstract
>>>>>> numbers only.
>>>>> <
>>>>> All integral container that do not explicitly need to contain negative
>>>>> numbers should be unsigned.
>>>> That also works.
>>>>
>>>> But if you are saying this because overflow is defined for unsigned
>>>> types in C, then I would disagree with the point - as overflow is
>>>> generally (but not always) a mistake, whether signed or unsigned, and
>>>> should not occur in normal code.
>>> <
>>> I am saying this because; unsigned arithmetic is much better defined
>>> than signed arithmetic in C. The surprise coefficient is way lower.
>>> <
>> Yes, that's what I thought. I disagree. When I use types for
>> arithmetic (outside of occasional very special cases, and bugs in my
>> code), the arithmetic does not overflow. Overflows are errors. It
>> doesn't matter what the language says - if I have 4294967295 apples in a
>> pile, put another apple on, and you tell me I now have 0 apples, it is
>> all nonsense.
> <
> It would not be nonsense on s 64-bit integer machine, and similar to
> the reason we no longer use 16-bit machines: the containers are no
> longer big enough and we can afford bigger containers.

Overflow would still be nonsense on 64-bit integers, just as it is on
16-bit and 32-bit integers (again, excluding a few special cases). But
with 64-bit integers you are far less likely to bump into overflow.

And if you are going to assume you are not going to overflow (after all,
who has 9 million million million apples in one pile?), then it doesn't
matter if overflow is defined or undefined behaviour and if you use
int64_t or uint64_t in C.

>>
>> So IMHO correctly written arithmetic code does not overflow. No
>> overflow, no surprises.
>>
>> It's fine to use unsigned types for data that is naturally non-negative.
>> It makes sense to the reader. And sometimes the extra bit of range is
>> useful.
>>
>> But if you think unsigned types are better for general purpose numbers
>> because they are "better defined", you are using the wrong types for the
>> arithmetic you are doing, or you have failed to check your values before
>> using them.
> <
> I write CPU simulators, 99% of the things these simulators do is to push
> piles of typeless bits around. Types are implied only sparingly along
> the path*. Nor, is the index to any CPU resource ever negative. The only
> place I need signed integers is when calling a library function hat
> requires a signed argument or delivers a singled result.
> <
> (*) For example a value read from the register file is typeless until it
> gets to the calculation unit and is typeless through the rest of the
> pipeline. It falls into the "just a bunch of bits" category. It is not
> signed, it is not unsigned either--it is signless:: a concept not yet
> supported by implementation languages. Unsigned is the slosest
> type to the desired type.

This is a rather specialised application. And clearly you have to model
exactly what the cpu would do, with a total disregard for whether the
simulated code is sensible or not.

>>
>> I lost my appetite decades ago for smart-arse code that relies on
>> overflows to see the end of a loop and that kind of thing. I write my
>> code to make sense - it says what it does, and does what it says,
>> instead of playing "bit twiddling tricks". Usually the result is not
>> only simpler and clearer, safer and more portable, but is at least as
>> efficient. In the extremely few cases where you need to do something
>> odd to squeeze the last clock cycle out of critical code, then you put
>> in the extra "unsigned" casts and other ugly details.
> <
> BTW I don't write code that overflows, in either sense.
>

Marcus <m.delete@this.bitsnbites.eu> schrieb:
> A common source of
> errors is implicit type conversions in C, for instance.

The integral promotions from signed to unsigned of the
same size are the worst.

int a = -3;
unsigned int b = 2;
if (a > b)
printf ("You expected this to happen, right?\n");

On 20/05/2021 21:31, Thomas Koenig wrote:
> Marcus <m.delete@this.bitsnbites.eu> schrieb:
>> A common source of
>> errors is implicit type conversions in C, for instance.
>
> The integral promotions from signed to unsigned of the
> same size are the worst.
>
> int a = -3;
> unsigned int b = 2;
> if (a > b)
> printf ("You expected this to happen, right?\n");
>

Yes, I think it's worth having gcc's warnings about mixing signed and
unsigned types to catch that kind of thing. (Of course it means the
inconvenience of a warning if "a" is always positive and the comparison
is safe.)

It's understandable that the language wants to convert both operands of
operators into a single type. But it should (IMHO) be done as
value-preserving (thus stepping up to a bigger signed type here), or be
an error if there is no such type available.

I'm not a fan of integer promotion either - I'd prefer operations to be
done on the types given.

Another fun example:

uint16_t a = 50000;
uint16_t b = a * a;

On a 16-bit int system, that is fully defined - you get b = (50000 *
50000) mod 0x10000, which is 63744.

On a 32-bit int system, "a" is first promoted to a 32-bit signed int.
Then 50000 * 50000 leads to an overflow, and thus undefined behaviour.

On a 64-bit int system, that calculation is done in 64 bit signed ints,
with no overflow, and then reduced mod 0x10000 to give 63744 again.

On Thursday, May 20, 2021 at 1:46:49 PM UTC-5, Bill Findlay wrote:
> On 20 May 2021, MitchAlsup wrote
> (in article<ec6f372d-d575-4cca...@googlegroups.com>):
> > On Wednesday, May 19, 2021 at 11:28:46 PM UTC-5, Stephen Fuld wrote:
> > > On 5/19/2021 9:32 AM, Thomas Koenig wrote:
> > > > EricP <ThatWould...@thevillage.com> schrieb:
> > > > > MitchAlsup wrote:
> > > > > > On Wednesday, May 19, 2021 at 7:23:04 AM UTC-5, Anton Ertl wrote:
> > > > > > > Thomas Koenig <tko...@netcologne.de> writes:
> > > > > > > > Anton Ertl<an...@mips.complang.tuwien.ac.at> schrieb:
> > > > > > > > > Thomas Koenig <tko...@netcologne.de> writes:
> > > > > > > > > > Unsigned loops can cause a headache, because it is often
> > > > > > > > > > not possible to prove they actually terminate...
> > > > > > > > > And the difference to signed loops is? Note that you wrote
> > > > > > > > > "actually", so pretending that signed overflow does not happen does
> > > > > > > > > not count.
> > > > > > > > According to many language definitions, it does indeed not
> > > > > > > > count.
> > > > > > > This sentence makes no sense.
> > > > > > <
> > > > > > How about this::
> > > > > > <
> > > > > > Languages, that want to be ported across multiple architectures, and
> > > > > > have high performing implementations, cannot specify that signed integers
> > > > > > overflow.
> > > > > > <
> > > > >
> > > > > The language spec should:
> > > > > - allow the programmer to choose between bounds-range checked,
> > > > > unchecked, modulo, or saturating data types
> > > >
> > > > That is not going to fly for an established, general-purpose
> > > > language.
> > <
> > > A counter example is Ada, which implements most of those things.
> > <
> > And ADA has taken over what corner of programming/programmers ?
> The corner where getting the right result is the most important criterion.
<
So, basically no where ?!?
>
> --
> Bill Findlay

On Thursday, May 20, 2021 at 2:20:14 PM UTC-5, David Brown wrote:
> On 20/05/2021 18:24, MitchAlsup wrote:
> > On Thursday, May 20, 2021 at 2:11:23 AM UTC-5, David Brown wrote:
> >> On 20/05/2021 04:12, MitchAlsup wrote:
> >>> On Wednesday, May 19, 2021 at 7:37:33 PM UTC-5, David Brown wrote:
> >>>> On 20/05/2021 01:54, MitchAlsup wrote:
> >>>>> On Wednesday, May 19, 2021 at 6:25:20 PM UTC-5, David Brown wrote:
> >>>>>> On 20/05/2021 00:11, Anton Ertl wrote:
> >>>>>>> David Brown <david...@hesbynett.no> writes:
> >>>>
> >>>>>>
> >>>>>> Perhaps it should also give the suggestion "you should be using unsigned
> >>>>>> types for this kind of thing". As a general rule, anything involving
> >>>>>> bit patterns should be unsigned types - signed types are for abstract
> >>>>>> numbers only.
> >>>>> <
> >>>>> All integral container that do not explicitly need to contain negative
> >>>>> numbers should be unsigned.
> >>>> That also works.
> >>>>
> >>>> But if you are saying this because overflow is defined for unsigned
> >>>> types in C, then I would disagree with the point - as overflow is
> >>>> generally (but not always) a mistake, whether signed or unsigned, and
> >>>> should not occur in normal code.
> >>> <
> >>> I am saying this because; unsigned arithmetic is much better defined
> >>> than signed arithmetic in C. The surprise coefficient is way lower.
> >>> <
> >> Yes, that's what I thought. I disagree. When I use types for
> >> arithmetic (outside of occasional very special cases, and bugs in my
> >> code), the arithmetic does not overflow. Overflows are errors. It
> >> doesn't matter what the language says - if I have 4294967295 apples in a
> >> pile, put another apple on, and you tell me I now have 0 apples, it is
> >> all nonsense.
> > <
> > It would not be nonsense on s 64-bit integer machine, and similar to
> > the reason we no longer use 16-bit machines: the containers are no
> > longer big enough and we can afford bigger containers.
> Overflow would still be nonsense on 64-bit integers, just as it is on
> 16-bit and 32-bit integers (again, excluding a few special cases). But
> with 64-bit integers you are far less likely to bump into overflow.
>
> And if you are going to assume you are not going to overflow (after all,
> who has 9 million million million apples in one pile?), then it doesn't
> matter if overflow is defined or undefined behaviour and if you use
> int64_t or uint64_t in C.
<
There are only 60G apples produced per year.
> >>
> >> So IMHO correctly written arithmetic code does not overflow. No
> >> overflow, no surprises.
> >>
> >> It's fine to use unsigned types for data that is naturally non-negative.
> >> It makes sense to the reader. And sometimes the extra bit of range is
> >> useful.
> >>
> >> But if you think unsigned types are better for general purpose numbers
> >> because they are "better defined", you are using the wrong types for the
> >> arithmetic you are doing, or you have failed to check your values before
> >> using them.
> > <
> > I write CPU simulators, 99% of the things these simulators do is to push
> > piles of typeless bits around. Types are implied only sparingly along
> > the path*. Nor, is the index to any CPU resource ever negative. The only
> > place I need signed integers is when calling a library function hat
> > requires a signed argument or delivers a singled result.
> > <
> > (*) For example a value read from the register file is typeless until it
> > gets to the calculation unit and is typeless through the rest of the
> > pipeline. It falls into the "just a bunch of bits" category. It is not
> > signed, it is not unsigned either--it is signless:: a concept not yet
> > supported by implementation languages. Unsigned is the slosest
> > type to the desired type.
<
> This is a rather specialised application. And clearly you have to model
> exactly what the cpu would do, with a total disregard for whether the
> simulated code is sensible or not.
<
It turns out that if you don't write sensible code you will never get
the simulation working.
> >>
> >> I lost my appetite decades ago for smart-arse code that relies on
> >> overflows to see the end of a loop and that kind of thing. I write my
> >> code to make sense - it says what it does, and does what it says,
> >> instead of playing "bit twiddling tricks". Usually the result is not
> >> only simpler and clearer, safer and more portable, but is at least as
> >> efficient. In the extremely few cases where you need to do something
> >> odd to squeeze the last clock cycle out of critical code, then you put
> >> in the extra "unsigned" casts and other ugly details.
> > <
> > BTW I don't write code that overflows, in either sense.
> >

> Another fun example:
>
> uint16_t a = 50000;
> uint16_t b = a * a;
>
> On a 16-bit int system, that is fully defined - you get b = (50000 *
> 50000) mod 0x10000, which is 63744.
>
> On a 32-bit int system, "a" is first promoted to a 32-bit signed int.
> Then 50000 * 50000 leads to an overflow, and thus undefined behaviour.

Ewww!!!!

Stefan

On 21/05/2021 03:37, Stefan Monnier wrote:
>> Another fun example:
>>
>> uint16_t a = 50000;
>> uint16_t b = a * a;
>>
>> On a 16-bit int system, that is fully defined - you get b = (50000 *
>> 50000) mod 0x10000, which is 63744.
>>
>> On a 32-bit int system, "a" is first promoted to a 32-bit signed int.
>> Then 50000 * 50000 leads to an overflow, and thus undefined behaviour.
>
> Ewww!!!!
>
>
> Stefan
>

I guess all programming languages have their warts, and design choices
that made sense at the time but had unexpected consequences later. C's
warts are mostly quite well known by now. But that particular one might
be new to some.

As Bjarne "C++" Stroustrup said, there are two kinds of programming
languages. Those that people complain about, and those that no one uses.

Terje Mathisen <terje.mathisen@tmsw.no> writes:
>Thomas Koenig wrote:
>> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>>
>>> The major downside is that the world has adapted to the unwise
>>> decision to go I32LP64 for ~30 years, so any change now incurs
>>> significant switching cost.
>>
>> You don't care about cache or memory bandwidth, then?
>>
>We all care about that, which is why all 64-bit cpus have to make usre
>that 32-bit ops are at least as fast as the register-sized 64-bit ones.

The only 32-bit-ops that need to be at least as fast as 64-bit ones
are load and store. With 64-bit ints, 32-bit register-to-register ops
would not be needed for C.

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

Thomas Koenig <tkoenig@netcologne.de> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>>>
>>>> The major downside is that the world has adapted to the unwise
>>>> decision to go I32LP64 for ~30 years, so any change now incurs
>>>> significant switching cost.
>>>
>>>You don't care about cache or memory bandwidth, then?
>>
>> When that plays a role, I use the appropriate in-memory
>> representation.
>
>You may not do so, but people still use unadorned "int" or "usigned
>int" in the reasonable expectation that it will give them good code.

Something that currently is not true, as the present case shows.

>With your suggestion, this would often not happen due to memory
>congestion.

Often? I doubt it. Sure, there might be such cases. And in those
cases the way to go is to define the few arrays and fields where it
does matter with, int32_t or uint32_t. Or maybe the programmer will
think more clearly about it, and find that, e.g., int16_t is enough
for some of these arrays or fields, and use that, reducing memory
consumption, bandwidth requirements and cache effects even more.

The reason you give is not a good reason to have int be 32 bits; C has
other types for that. int plays a special role in C: e.g., chars and
shorts are converted to int for arithmetic operations.

Admittedly, this discussion is 30 years late, and it's too late to
correct this decision. But it's not too late to admit that I32LP64
was a dumb idea. The present thread shows this nicely.

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

Thomas Koenig wrote:
> EricP <ThatWouldBeTelling@thevillage.com> schrieb:
>
> Coming back.
>> The language spec should:
>> - allow the programmer to choose between bounds-range checked,
>> unchecked, modulo, or saturating data types
>
> That would be an interesting language design...
>
> Using Fortran's attribute syntax here, because it
> could easily be extended:
>
> integer, unchecked :: i
> integer, modulo :: j
> integer, saturating :: n
>
> Just a few question about this...

Note that I don't actually care about saturating arithmetic.
I'm using it as a place card holder for "another integer type".

The language rules design must take into account the variation
that the following types many of which already exist:

Binary Floating Point (BFP) has various data types:
- x86/x64 FP80
- IBM z-series has hex floats,plus IEEE FP
- Alpha had VAX F (32) and D (64), plus IEEE FP32 and FP64,
- I believe there are implementations with IEEE FP16
- Some people are talking about IEEE FP128
- Some people are talking about IEEE FP8 and other FP8 formats for neurons
- Some people are implementing various Posit sizes

And we have 2 standard implementations of decimal floating point (DFP)
with different physical representation and operator functions.

I'm assuming strong typing so the behavior is always well defined.
That implies constants also have a type, either explicit or inferred.

The rules for optimization may be different for different types.
And parenthesis may be important for optimizations.

> Should integer constants also have these properties?

If you mean lexical literal values, yes.

Note you can validate lexically but not convert to a type until the
expression is evaluated. This is necessary for BFP and DFP types
where the conversion precision is based on the target type.

i.e. the conversion of 3.141592654 is different for
FP16, FP32, FP64, FP32_HEX, FP64_HEX, Posit32, Posit64, FP_Decimal(n).

> What about named constants (parameters in Fortran parlance)?

Yes, they need to be typed.
For integer types except modulo and floating point,
overflow in a constant as a compile error.

For modulo integer, its purpose is to have a number system that works
the way the hardware actually works, for calculating addresses, etc.

What is clear is that the rules for correct optimization are type dependent.
BFP is not the same as integer, parenthesis can matter, and associativity
and distributivity rules are type dependent.

> What about mixed expressions, how would they work (or not)?

Strong typing implies there are always explicit conversions.

> What about expressions using different integer sizes?

This is subtype promotions and demotions and depends on the type.

For unchecked and modulo integers, demotions are by truncation
and do not require an explicit conversion.

Checked integers require an explicit conversion,
and are range checked with a potential exception.

Saturate integers require an explicit conversion,
and are range checked with potential saturation.

Note that BFP and DFP floats can also have ranges.

> a saturating argument, should it also require a saturating argument
> as actual argument or should that be rejected or warned about?

Strong typing requires the types must match.

> Or do you want to make the these attributes a function
> of the operators? Have a signed addition, a modulo
> addition, a saturating addition operator in the language?

No, I would not use separate operator symbols for different types.
I have seen this done in a language and it was a mess.
Are you going to add more operators for DFP and Posits?

Normal data type based bottom-up operator overload resolution works fine.
C's integer rules are a mess but that's for historical reasons.

I'm not a fan of general, user defined overloading though.
It becomes impossible to figure out what any piece of code does.
So just language defined overloading.

> None of these questions are unsolvable (obviously), but you need
> to think carefully about what the answer should be.
>
> Language design is _hard_, and there are many traps for the unwary,
> as evidenced by the many warts and quirks of existing languages.

Right, but I still think we can do better than the endless series
of completely avoidable buffer overflow bugs that we have now.

And one step on that path is giving programmers tools that minimize
the chance of mistakes in the first place, and allow programs to
detect and diagnose its own errors as much as possible.

Stephen Fuld wrote:
> On 5/19/2021 8:47 AM, EricP wrote:
>> MitchAlsup wrote:
>>> On Wednesday, May 19, 2021 at 7:23:04 AM UTC-5, Anton Ertl wrote:
>>>> Thomas Koenig <tko...@netcologne.de> writes:
>>>>> Anton Ertl <an...@mips.complang.tuwien.ac.at> schrieb:
>>>>>> Thomas Koenig <tko...@netcologne.de> writes:
>>>>>>> Unsigned loops can cause a headache, because it is often not
>>>>>>> possible to prove they actually terminate...
>>>>>> And the difference to signed loops is? Note that you wrote
>>>>>> "actually", so pretending that signed overflow does not happen
>>>>>> does not count.
>>>>> According to many language definitions, it does indeed not count.
>>>> This sentence makes no sense.
>>> <
>>> How about this::
>>> <
>>> Languages, that want to be ported across multiple architectures, and
>>> have high performing implementations, cannot specify that signed
>>> integers overflow.
>>> <
>>
>> The language spec should:
>> - allow the programmer to choose between bounds-range checked,
>> unchecked, modulo, or saturating data types
>
> Ada allows range checked, i.e. Range 20-100, unchecked, at least within
> the limits of the size, and Modulo variables. I suspect adding
> saturated wouldn't be a big stretch if it were popular enough.
> Saturating would be pretty inexpensive to check, especially if you have
> something like a CMOV instruction.
>
>
>> - specify that range and array bounds checks can be enabled or disabled
>> at compile time by command line options or inline pragmas,
>> for blocks of code, individual data types, or individual objects.
>
> Since Ada supports Range attributes, and you can use a range restricted
> variable as a subscript or loop limit, I think you can do all of that.
>
> But Nick Holsti is the Ada expert around here, so perhaps he will chime in.

Ada defines support for checked signed integers,
and later added unchecked modulo integers.
Checked signed integers and floats can have arbitrary subtype ranges.
So that part matches what I said.

I like most of the Ada's subtyping. I eventually came to disliked that
subtype conversions were automatic. The problem is that a subtype range
check can raise an exception but that was invisible in the source code.
I would prefer
c = Char (i);
as that gives you a heads-up that a conversion is taking place.
Basically I prefer what C with warnings does.

I also liked derived types though I recall problems with
user defined operator overloading and literal values.

But I gave up on overloading as just causing confusion as
one can never tell what a piece of code does by just looking,
and its impossible to search for all references to a particular routine.
This made maintenance difficult and error prone and a lot more work.

The rest of it I either had no use for, or disliked to varying degrees.

On Friday, May 21, 2021 at 10:58:26 AM UTC-5, EricP wrote:
> Stephen Fuld wrote:
> > On 5/19/2021 8:47 AM, EricP wrote:
> >> MitchAlsup wrote:
> >>> On Wednesday, May 19, 2021 at 7:23:04 AM UTC-5, Anton Ertl wrote:
> >>>> Thomas Koenig <tko...@netcologne.de> writes:
> >>>>> Anton Ertl <an...@mips.complang.tuwien.ac.at> schrieb:
> >>>>>> Thomas Koenig <tko...@netcologne.de> writes:
> >>>>>>> Unsigned loops can cause a headache, because it is often not
> >>>>>>> possible to prove they actually terminate...
> >>>>>> And the difference to signed loops is? Note that you wrote
> >>>>>> "actually", so pretending that signed overflow does not happen
> >>>>>> does not count.
> >>>>> According to many language definitions, it does indeed not count.
> >>>> This sentence makes no sense.
> >>> <
> >>> How about this::
> >>> <
> >>> Languages, that want to be ported across multiple architectures, and
> >>> have high performing implementations, cannot specify that signed
> >>> integers overflow.
> >>> <
> >>
> >> The language spec should:
> >> - allow the programmer to choose between bounds-range checked,
> >> unchecked, modulo, or saturating data types
> >
> > Ada allows range checked, i.e. Range 20-100, unchecked, at least within
> > the limits of the size, and Modulo variables. I suspect adding
> > saturated wouldn't be a big stretch if it were popular enough.
> > Saturating would be pretty inexpensive to check, especially if you have
> > something like a CMOV instruction.
> >
> >
> >> - specify that range and array bounds checks can be enabled or disabled
> >> at compile time by command line options or inline pragmas,
> >> for blocks of code, individual data types, or individual objects.
> >
> > Since Ada supports Range attributes, and you can use a range restricted
> > variable as a subscript or loop limit, I think you can do all of that.
> >
> > But Nick Holsti is the Ada expert around here, so perhaps he will chime in.
> Ada defines support for checked signed integers,
> and later added unchecked modulo integers.
> Checked signed integers and floats can have arbitrary subtype ranges.
> So that part matches what I said.
>
> I like most of the Ada's subtyping. I eventually came to disliked that
> subtype conversions were automatic. The problem is that a subtype range
> check can raise an exception but that was invisible in the source code.
> I would prefer
> c = Char (i);
> as that gives you a heads-up that a conversion is taking place.
> Basically I prefer what C with warnings does.
>
> I also liked derived types though I recall problems with
> user defined operator overloading and literal values.
>
> But I gave up on overloading as just causing confusion as
> one can never tell what a piece of code does by just looking,
<
Which is why I never got INTO overloading !
<
> and its impossible to search for all references to a particular routine.
> This made maintenance difficult and error prone and a lot more work.
<
And the only way to fix this would be for the compiler to keep a symbol
table of all call points (including all inlined code) so you could search it
by overloaded name.
>
> The rest of it I either had no use for, or disliked to varying degrees.

Stephen Fuld wrote:
> On 5/20/2021 9:34 AM, MitchAlsup wrote:
>> On Thursday, May 20, 2021 at 10:08:32 AM UTC-5, Stephen Fuld wrote:
>>> On 5/19/2021 11:40 PM, Niklas Holsti wrote:
>>>> On 2021-05-20 3:40, Stephen Fuld wrote:
>>>>> On 5/19/2021 8:47 AM, EricP wrote:
>>
>>> Fair enough. This sort of gets back to the question of whether to add a
>>> feature like this as an attribute of the variable (e.g. range) or of the
>>> operation (e.g. bignum). I think there are arguments for each.
>>>
>>> BTW, I am unsure of what the requirement is here. Suppose you have a
>>> variable with a range of 10-90. Do you want saturation at 90? That is
>> <
>> If the value to be written is outside of the range [10..90] you raise an
>> exception. The raised exception decides what to do.
>
> Certainly true for the non-saturating case, and is what Ada does. My
> question is if you define saturating variables, what to do if you
> somehow define the variable with a range *and* saturating.

Any variables that are smaller than the machine register size are
promoted to that size by either sign or zero extension.

Expressions are executed using signed or unsigned checked or saturating
operations at that machine size. This detects intermediate signed or
unsigned overflows of the machine size results.

I have instructions for trap on unsigned carry or signed overflow.
I have an ADGO Add Generate Overflow and ADGC Add Generate Carry
to set a 1 in the output register for overflow or carry.
Then a LIC Load Immediate Conditional loads saturation limit values.
One could have arithmetic instructions that saturate.

The result is copied back to the variable. If there are constraints on
the variable different from the limits on the physical register
then those are range checked and either saturated or trapped.
A CMPGT and CMPLT with a LIC loads upper or lower saturation value.

Note that setting limits on variable to be in the range 10..90 does
not mean that expression intermediate results are within that range.
It means an expression EITHER produces the arithmetically correct result
in that range, or it saturates or traps.

On Friday, May 21, 2021 at 2:41:13 PM UTC-5, EricP wrote:
> Stephen Fuld wrote:
> > On 5/20/2021 9:34 AM, MitchAlsup wrote:
> >> On Thursday, May 20, 2021 at 10:08:32 AM UTC-5, Stephen Fuld wrote:
> >>> On 5/19/2021 11:40 PM, Niklas Holsti wrote:
> >>>> On 2021-05-20 3:40, Stephen Fuld wrote:
> >>>>> On 5/19/2021 8:47 AM, EricP wrote:
> >>
> >>> Fair enough. This sort of gets back to the question of whether to add a
> >>> feature like this as an attribute of the variable (e.g. range) or of the
> >>> operation (e.g. bignum). I think there are arguments for each.
> >>>
> >>> BTW, I am unsure of what the requirement is here. Suppose you have a
> >>> variable with a range of 10-90. Do you want saturation at 90? That is
> >> <
> >> If the value to be written is outside of the range [10..90] you raise an
> >> exception. The raised exception decides what to do.
> >
> > Certainly true for the non-saturating case, and is what Ada does. My
> > question is if you define saturating variables, what to do if you
> > somehow define the variable with a range *and* saturating.
<
> Any variables that are smaller than the machine register size are
> promoted to that size by either sign or zero extension.
>
> Expressions are executed using signed or unsigned checked or saturating
> operations at that machine size. This detects intermediate signed or
> unsigned overflows of the machine size results.
>
> I have instructions for trap on unsigned carry or signed overflow.
> I have an ADGO Add Generate Overflow and ADGC Add Generate Carry
> to set a 1 in the output register for overflow or carry.
<
And throw the actual add away ?
<
> Then a LIC Load Immediate Conditional loads saturation limit values.
> One could have arithmetic instructions that saturate.
>
> The result is copied back to the variable. If there are constraints on
> the variable different from the limits on the physical register
> then those are range checked and either saturated or trapped.
> A CMPGT and CMPLT with a LIC loads upper or lower saturation value.
>
> Note that setting limits on variable to be in the range 10..90 does
> not mean that expression intermediate results are within that range.
> It means an expression EITHER produces the arithmetically correct result
> in that range, or it saturates or traps.
<
I am curious:
<
x, y, and z are range [10..90]: what is the result of:
<
x = y + ( z-x )
< versus
x = ( y+z ) - x
< given that the non-overflowing arithmetic creates a result in the range [10..90] ?

That is, does the arithmetic get checked, or does the delivery of a value into a variable
get checked ?
<
What about::
<
x = y*z/x;
? where the multiply is either non-overflowing, or performed to double width
and the divide is also of double width.

On 5/21/2021 12:40 PM, EricP wrote:
> Stephen Fuld wrote:
>> On 5/20/2021 9:34 AM, MitchAlsup wrote:
>>> On Thursday, May 20, 2021 at 10:08:32 AM UTC-5, Stephen Fuld wrote:
>>>> On 5/19/2021 11:40 PM, Niklas Holsti wrote:
>>>>> On 2021-05-20 3:40, Stephen Fuld wrote:
>>>>>> On 5/19/2021 8:47 AM, EricP wrote:
>>>
>>>> Fair enough. This sort of gets back to the question of whether to add a
>>>> feature like this as an attribute of the variable (e.g. range) or of
>>>> the
>>>> operation (e.g. bignum). I think there are arguments for each.
>>>>
>>>> BTW, I am unsure of what the requirement is here. Suppose you have a
>>>> variable with a range of 10-90. Do you want saturation at 90? That is
>>> <
>>> If the value to be written is outside of the range [10..90] you raise an
>>> exception. The raised exception decides what to do.
>>
>> Certainly true for the non-saturating case, and is what Ada does.  My
>> question is if you define saturating variables, what to do if you
>> somehow define the variable with a range *and* saturating.
>
> Any variables that are smaller than the machine register size are
> promoted to that size by either sign or zero extension.
>
> Expressions are executed using signed or unsigned checked or saturating
> operations at that machine size. This detects intermediate signed or
> unsigned overflows of the machine size results.
>
> I have instructions for trap on unsigned carry or signed overflow.
> I have an ADGO Add Generate Overflow and ADGC Add Generate Carry
> to set a 1 in the output register for overflow or carry.
> Then a LIC Load Immediate Conditional loads saturation limit values.
> One could have arithmetic instructions that saturate.
>
> The result is copied back to the variable. If there are constraints on
> the variable different from the limits on the physical register
> then those are range checked and either saturated or trapped.
> A CMPGT and CMPLT with a LIC loads upper or lower saturation value.
>
> Note that setting limits on variable to be in the range 10..90 does
> not mean that expression intermediate results are within that range.
> It means an expression EITHER produces the arithmetically correct result
> in that range, or it saturates or traps.

That is certainly one way to do it. All the different ways have
drawbacks. Mitch pointed out some of the ones for you choice in his
followup.

I don't know enough to have strong feelings as to the best choice. As
Thomas Koening said earlier in this thread, it takes a lot of thought.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On Friday, May 21, 2021 at 5:00:17 PM UTC-5, Stephen Fuld wrote:
> On 5/21/2021 12:40 PM, EricP wrote:
> > Stephen Fuld wrote:
> >> On 5/20/2021 9:34 AM, MitchAlsup wrote:
> >>> On Thursday, May 20, 2021 at 10:08:32 AM UTC-5, Stephen Fuld wrote:
> >>>> On 5/19/2021 11:40 PM, Niklas Holsti wrote:
> >>>>> On 2021-05-20 3:40, Stephen Fuld wrote:
> >>>>>> On 5/19/2021 8:47 AM, EricP wrote:
> >>>
> >>>> Fair enough. This sort of gets back to the question of whether to add a
> >>>> feature like this as an attribute of the variable (e.g. range) or of
> >>>> the
> >>>> operation (e.g. bignum). I think there are arguments for each.
> >>>>
> >>>> BTW, I am unsure of what the requirement is here. Suppose you have a
> >>>> variable with a range of 10-90. Do you want saturation at 90? That is
> >>> <
> >>> If the value to be written is outside of the range [10..90] you raise an
> >>> exception. The raised exception decides what to do.
> >>
> >> Certainly true for the non-saturating case, and is what Ada does. My
> >> question is if you define saturating variables, what to do if you
> >> somehow define the variable with a range *and* saturating.
> >
> > Any variables that are smaller than the machine register size are
> > promoted to that size by either sign or zero extension.
> >
> > Expressions are executed using signed or unsigned checked or saturating
> > operations at that machine size. This detects intermediate signed or
> > unsigned overflows of the machine size results.
> >
> > I have instructions for trap on unsigned carry or signed overflow.
> > I have an ADGO Add Generate Overflow and ADGC Add Generate Carry
> > to set a 1 in the output register for overflow or carry.
> > Then a LIC Load Immediate Conditional loads saturation limit values.
> > One could have arithmetic instructions that saturate.
> >
> > The result is copied back to the variable. If there are constraints on
> > the variable different from the limits on the physical register
> > then those are range checked and either saturated or trapped.
> > A CMPGT and CMPLT with a LIC loads upper or lower saturation value.
> >
> > Note that setting limits on variable to be in the range 10..90 does
> > not mean that expression intermediate results are within that range.
> > It means an expression EITHER produces the arithmetically correct result
> > in that range, or it saturates or traps.
<
> That is certainly one way to do it. All the different ways have
> drawbacks. Mitch pointed out some of the ones for you choice in his
> followup.
>
> I don't know enough to have strong feelings as to the best choice. As
> Thomas Koening said earlier in this thread, it takes a lot of thought.
<
This brings to mind that the whole concept of arithmetic exceptions is
fundamentally flawed.
<
It is not the arithmetic that should be checked for out-of-range values
it is the depositing of values into containers that should be checked.
<
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

On 20 May 2021, MitchAlsup wrote
(in article<c54a6872-789c-4946-b200-17d24728af62n@googlegroups.com>):

> On Thursday, May 20, 2021 at 1:46:49 PM UTC-5, Bill Findlay wrote:
> > On 20 May 2021, MitchAlsup wrote
> > (in article<ec6f372d-d575-4cca...@googlegroups.com>):
> > > On Wednesday, May 19, 2021 at 11:28:46 PM UTC-5, Stephen Fuld wrote:
> > > > On 5/19/2021 9:32 AM, Thomas Koenig wrote:
> > > > > EricP <ThatWould...@thevillage.com> schrieb:
> > > > > > MitchAlsup wrote:
> > > > > > > On Wednesday, May 19, 2021 at 7:23:04 AM UTC-5, Anton Ertl wrote:
> > > > > > > > Thomas Koenig <tko...@netcologne.de> writes:
> > > > > > > > > Anton Ertl<an...@mips.complang.tuwien.ac.at> schrieb:
> > > > > > > > > > Thomas Koenig <tko...@netcologne.de> writes:
> > > > > > > > > > > Unsigned loops can cause a headache, because it is often
> > > > > > > > > > > not possible to prove they actually terminate...
> > > > > > > > > > And the difference to signed loops is? Note that you wrote
> > > > > > > > > > "actually", so pretending that signed overflow does not happen does
> > > > > > > > > > not count.
> > > > > > > > > According to many language definitions, it does indeed not
> > > > > > > > > count.
> > > > > > > > This sentence makes no sense.
> > > > > > > <
> > > > > > > How about this::
> > > > > > > <
> > > > > > > Languages, that want to be ported across multiple architectures, and
> > > > > > > have high performing implementations, cannot specify that signed
> > > > > > > integers
> > > > > > > overflow.
> > > > > > > <
> > > > > >
> > > > > > The language spec should:
> > > > > > - allow the programmer to choose between bounds-range checked,
> > > > > > unchecked, modulo, or saturating data types
> > > > >
> > > > > That is not going to fly for an established, general-purpose
> > > > > language.
> > > <
> > > > A counter example is Ada, which implements most of those things.
> > > <
> > > And ADA has taken over what corner of programming/programmers ?
> > The corner where getting the right result is the most important criterion.
>
> So, basically no where ?!?

Regrettably, almost nowhere.

--
Bill Findlay

On 21 May 2021, MitchAlsup wrote
(in article<26c0c173-a5b3-4852-8bb9-914ad7252f05n@googlegroups.com>):

> On Friday, May 21, 2021 at 5:00:17 PM UTC-5, Stephen Fuld wrote:
> > On 5/21/2021 12:40 PM, EricP wrote:
> > > Stephen Fuld wrote:
> > > > On 5/20/2021 9:34 AM, MitchAlsup wrote:
> > > > > On Thursday, May 20, 2021 at 10:08:32 AM UTC-5, Stephen Fuld wrote:
> > > > > > On 5/19/2021 11:40 PM, Niklas Holsti wrote:
> > > > > > > On 2021-05-20 3:40, Stephen Fuld wrote:
> > > > > > > > On 5/19/2021 8:47 AM, EricP wrote:
> > > > >
> > > > > > Fair enough. This sort of gets back to the question of whether to add a
> > > > > > feature like this as an attribute of the variable (e.g. range) or of
> > > > > > the
> > > > > > operation (e.g. bignum). I think there are arguments for each.
> > > > > >
> > > > > > BTW, I am unsure of what the requirement is here. Suppose you have a
> > > > > > variable with a range of 10-90. Do you want saturation at 90? That is
> > > > > <
> > > > > If the value to be written is outside of the range [10..90] you raise an
> > > > > exception. The raised exception decides what to do.
> > > >
> > > > Certainly true for the non-saturating case, and is what Ada does. My
> > > > question is if you define saturating variables, what to do if you
> > > > somehow define the variable with a range *and* saturating.
> > >
> > > Any variables that are smaller than the machine register size are
> > > promoted to that size by either sign or zero extension.
> > >
> > > Expressions are executed using signed or unsigned checked or saturating
> > > operations at that machine size. This detects intermediate signed or
> > > unsigned overflows of the machine size results.
> > >
> > > I have instructions for trap on unsigned carry or signed overflow.
> > > I have an ADGO Add Generate Overflow and ADGC Add Generate Carry
> > > to set a 1 in the output register for overflow or carry.
> > > Then a LIC Load Immediate Conditional loads saturation limit values.
> > > One could have arithmetic instructions that saturate.
> > >
> > > The result is copied back to the variable. If there are constraints on
> > > the variable different from the limits on the physical register
> > > then those are range checked and either saturated or trapped.
> > > A CMPGT and CMPLT with a LIC loads upper or lower saturation value.
> > >
> > > Note that setting limits on variable to be in the range 10..90 does
> > > not mean that expression intermediate results are within that range.
> > > It means an expression EITHER produces the arithmetically correct result
> > > in that range, or it saturates or traps.
> <
> > That is certainly one way to do it. All the different ways have
> > drawbacks. Mitch pointed out some of the ones for you choice in his
> > followup.
> >
> > I don't know enough to have strong feelings as to the best choice. As
> > Thomas Koening said earlier in this thread, it takes a lot of thought.
> <
> This brings to mind that the whole concept of arithmetic exceptions is
> fundamentally flawed.
> <
> It is not the arithmetic that should be checked for out-of-range values
> it is the depositing of values into containers that should be checked.

That is precisely what is checked in Ada.
Types are properties of containers, not of values.
Of course, with current architectures, the destination
operand of an arithmetic operation is de facto a container
with its hardware-defined range.

--
Bill Findlay