On 10/16/2021 3:49 AM, Thomas Koenig wrote:
> MitchAlsup <MitchAlsup@aol.com> schrieb:
>
>> This, however, is a NG devoted to architectures that can run C and
>> all sorts of other languages. Architectures and implementations of
>> those architectures.
>>
>> It should a design goal of any architect to provide an efficient and
>> straightforward instruction set that enables compilers to produce
>> small, efficient, correct applications from a given set of source code.
>
> You are, of course, correct.
>
> There is another goal, which is to have zero or low overhead for
> error checking. If I may quote C.A.R. Hoare:
>
> # Finally, it is absurd to make elaborate security checks on debugging
> # runs, when no trust is put in the results, and then remove them
> # in production runs, when an erroneous result could be expensive
> # or disastrous. What would we think of a sailing enthusiast who
> # wears his lifejacket when training on dry land, but takes it off
> # as soon as he goes to sea?
>
> The reason for this is that some languages like C make error
> checking very difficult (for example, finding out the valid range
> for pointer arithmetic in a function needs information from the
> caller, which is not available via the standard language).
>
> There are languages where the necessary info is provided, Ada
> and Fortran among them. However, that there is a rather large
> overhead in code size and, more importantly, execution time.
> IIRC (but correct me if I'm wrong) even gnat comes which range
> checking switched off by default.
>
> To extend the metaphor above, the lifejacket comes combined with
> a sea anchor, which is not good if you want to go somewhere.
>
> There are a couple of notorious bug classes which surface again
> and again. Buffer overruns are a classic, as are "use after free"
> errors and signed overruns.
>
> First, buffer overruns. Compilers need to become better at moving
> checking code out of loops. One idea that could help (with compiler
> support, of course) is to define a valid range for a register
> (which could hold an address to an array or an index) to be in
> for a certain amount of instructions, trapping if it is outside.
> Maybe a few "range registers" with a way to associate a certain
> register with them, to allow spill / restore.
>
> Signed overruns - the very topic we are discussing here. Integer
> arithmetic could (optionally) trap on a 64-bit overflow, a 32-bit
> overflow, a 16-bit overflow and an 8-bit overflow.
>
> Use after free - much more difficult. It might be possible to
> have a hardware list of "poisoned" address ranges from which it is
> not permitted to load. Very expensive (comparable to
> cache) and would probably cache only the most recently freed
> memory blocks. Not sure if this is worth it.
>
> 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.

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

On 15/10/2021 17:38, Victor Yodaiken wrote:
> On Friday, October 15, 2021 at 10:11:49 AM UTC-5, David Brown wrote:
>
>> In C, some people think wrapping signed integer overflow is a perfectly
>> reasonable choice of behaviour - that does not make it defined behaviour
>> in C, and it does not stop programs that rely on such behaviour from
>> being incorrect and program errors.
>
> When gcc/clang are used with the fwrapv flag, they define integer overflow to wrap
> as they are permitted to do by the C standard. Programs that rely on that behavior
> are not incorrect.
>

That is absolutely correct - /if/ you use those compilers, with that flag.

Correctness of code can be independent of the implementation (meaning
the particular compiler, version, target and flag combination), or it
can be /dependent/ on the implementation. There's nothing wrong with
writing non-portable code, and indeed such code is absolutely essential
to programming.

The problems come when people take non-portable code that is correct in
certain circumstances, and assume it is correct in other circumstances.
Blaming the tools when this happens does not help.

I've occasionally had reason to use -fwrapv or -fno-strict-aliasing,
typically when getting questionable code from elsewhere to work with
modern optimised gcc. I do this by adding pragmas to the code, rather
than adding these flags to the makefile - pragmas are safer, more robust
and give better documentation because they are attached directly to the
code that needs them.

> There is nothing in the C standard that privileges one interpretation of C UB over
> another one.
>

Correct.

This also means that assuming the UB does not occur is just as valid as
using wrapping behaviour, as far as the standards are concerned.
/People/ can, of course, have different opinions about the suitability
of different interpretations or implementations of UB here - but the
standards provide no bias.

MitchAlsup <MitchAlsup@aol.com> writes:
>What could be changed in the FETCH unit to make those C un-specifications
>better?
><
>What could be changed in the DECODE unit to make those C un-specifications
>better?

I don't think that C is affected by that.

>What could be changed in the EXECUTE unit to make those C un-specifications
>better?

What do you mean with "the EXECUTE unit"? There seem to be a lot of
functional units.

>What could be changed in the AGEN unit to make those C un-specifications
>better?
><
>What could be changed in the LDALIGN unit to make those C un-specifications
>better?

One interesting aspect here is that Intel has always supported
unaligned accesses (including specifying calling conventions that made
setting the alignment bit (that they also provided) a no-go). Then
they introduced SSE and required 16-byte (not element) alignment for
load-op and RMW instructions as well was for some pure load and store
instructions, but at least they provided unaligned variants of the
pure instructions. AMD fixed that mistake by Intel by providing a
flag (unfortunately Intel did not pick that up). Intel finally fixed
that mistake with AVX, where the load-op and RMW instructions do not
require alignment. But Intel provided both variants of pure
instructions.

And of course the gcc people select the variant that requires
alignment in their auto-vectorizer, breaking previously working code.

What could be changed? Intel and AMD could make the instructions that
require alignment slower than the ones that do not. It's unclear if
that would help, see
<http://www.complang.tuwien.ac.at/anton/autovectors/> for some reason
to doubt this.

>What could be changed in the MEMORY-Model to make those C un-specifications
>better?

I don't know if C already has a memory model for shared memory, but
implementing sequential consistency in hardware at no extra cost for
non-shared accesses could make it nicer to use. Basically one would
ask for sequential consistency and forget about all the weaker
options.

>Just what pieces of HW could be made better enough to make your discussion of
>C (un)specified behavior take 10% as long as it has already taken ?

It's true. The problem is not current hardware, but hardware from the
1960s that, e.g., did not have 2s-complement, which gave rise to the
signed integer undefined behaviour on overflow. And now that compiler
writers think that this gives them some edge, they will never let go
of this undefined behaviour until C vanishes in oblivion.

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

Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>
> [...]
>
>> There is also the restriction on the complexity, which makes
>>
>> #! /bin/sh
>> echo "Program to complex, aborting" 1>&2
>>
>> a valid C compiler according to the standard.
>
> Not true. Feel free to ask in comp.std.c if you want
> to understand why.

I'd be interested, but why not have it out in this forum
where the discussion started out?

On 15/10/2021 19:26, MitchAlsup wrote:
> You know, there is a very fine NG suited to discuss the nuances of C,
> what it is, what it is not, and what has been left grey {intentionally,
> or by omission}: comp.lan.c
>
> This, however, is a NG devoted to architectures that can run C and
> all sorts of other languages. Architectures and implementations of
> those architectures.
>
> It should a design goal of any architect to provide an efficient and
> straightforward instruction set that enables compilers to produce
> small, efficient, correct applications from a given set of source code.
>
> The past has taught us that a deft hand is required to put in enough
> "stuff" to make the expression of the compiler efficient, and leave
> out enough "stuff" to allow the implementations to be fast and
> efficient. This paragraph should be what a discussion of what C in
> this NG should be is about--what goes in ISA to make the compiler's
> expression efficient, and what stays out of ISA that makes the
> implementations efficient.
>
> I would suggest what stays out and what goes ISA in has changed
> "a bit" since the RISC revolution burst onto the scene and then withered.
>

Perhaps an interesting topic might be a look at how an ISA could be made
that worked better with UB (in C or other languages)? Is there a way to
introduce quiet and signalling NaN's to integers in an architecture?
Could a concept of UB, or unspecified values, be efficiently included in
a CPU - and could it even allow more efficient operation? Could "fat
pointers" work well to catch UB and bugs early?

I think maybe there's scope for a new thread on those lines.

On 10/16/2021 7:21 AM, Stephen Fuld wrote:
> On 10/16/2021 3:49 AM, Thomas Koenig wrote:
>> MitchAlsup <MitchAlsup@aol.com> schrieb:
>>
>>> This, however, is a NG devoted to architectures that can run C and
>>> all sorts of other languages. Architectures and implementations of
>>> those architectures.
>>>
>>> It should a design goal of any architect to provide an efficient and
>>> straightforward instruction set that enables compilers to produce
>>> small, efficient, correct applications from a given set of source code.
>>
>> You are, of course, correct.
>>
>> There is another goal, which is to have zero or low overhead for
>> error checking.  If I may quote C.A.R. Hoare:
>>
>> # Finally, it is absurd to make elaborate security checks on debugging
>> # runs, when no trust is put in the results, and then remove them
>> # in production runs, when an erroneous result could be expensive
>> # or disastrous.  What would we think of a sailing enthusiast who
>> # wears his lifejacket when training on dry land, but takes it off
>> # as soon as he goes to sea?
>>
>> The reason for this is that some languages like C make error
>> checking very difficult (for example, finding out the valid range
>> for pointer arithmetic in a function needs information from the
>> caller, which is not available via the standard language).
>>
>> There are languages where the necessary info is provided, Ada
>> and Fortran among them.  However, that there is a rather large
>> overhead in code size and, more importantly, execution time.
>> IIRC (but correct me if I'm wrong) even gnat comes which range
>> checking switched off by default.
>>
>> To extend the metaphor above, the lifejacket comes combined with
>> a sea anchor, which is not good if you want to go somewhere.
>>
>> There are a couple of notorious bug classes which surface again
>> and again.  Buffer overruns are a classic, as are "use after free"
>> errors and signed overruns.
>>
>> First, buffer overruns.  Compilers need to become better at moving
>> checking code out of loops.  One idea that could help (with compiler
>> support, of course) is to define a valid range for a register
>> (which could hold an address to an array or an index) to be in
>> for a certain amount of instructions, trapping if it is outside.
>> Maybe a few "range registers" with a way to associate a certain
>> register with them, to allow spill / restore.
>>
>> Signed overruns - the very topic we are discussing here.  Integer
>> arithmetic could (optionally) trap on a 64-bit overflow, a 32-bit
>> overflow, a 16-bit overflow and an 8-bit overflow.
>>
>> Use after free - much more difficult.  It might be possible to
>> have a hardware list of "poisoned" address ranges from which it is
>> not permitted to load.  Very expensive (comparable to
>> cache) and would probably cache only the most recently freed
>> memory blocks.  Not sure if this is worth it.
>>
>> 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.

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.

On 10/16/2021 7:39 AM, David Brown wrote:
> On 15/10/2021 19:26, MitchAlsup wrote:
>> You know, there is a very fine NG suited to discuss the nuances of C,
>> what it is, what it is not, and what has been left grey {intentionally,
>> or by omission}: comp.lan.c
>>
>> This, however, is a NG devoted to architectures that can run C and
>> all sorts of other languages. Architectures and implementations of
>> those architectures.
>>
>> It should a design goal of any architect to provide an efficient and
>> straightforward instruction set that enables compilers to produce
>> small, efficient, correct applications from a given set of source code.
>>
>> The past has taught us that a deft hand is required to put in enough
>> "stuff" to make the expression of the compiler efficient, and leave
>> out enough "stuff" to allow the implementations to be fast and
>> efficient. This paragraph should be what a discussion of what C in
>> this NG should be is about--what goes in ISA to make the compiler's
>> expression efficient, and what stays out of ISA that makes the
>> implementations efficient.
>>
>> I would suggest what stays out and what goes ISA in has changed
>> "a bit" since the RISC revolution burst onto the scene and then withered.
>>
>
> Perhaps an interesting topic might be a look at how an ISA could be made
> that worked better with UB (in C or other languages)? Is there a way to
> introduce quiet and signalling NaN's to integers in an architecture?
> Could a concept of UB, or unspecified values, be efficiently included in
> a CPU - and could it even allow more efficient operation? Could "fat
> pointers" work well to catch UB and bugs early?
>
> I think maybe there's scope for a new thread on those lines.
>

You mean Mill NaRs?

Thomas Koenig <tkoenig@netcologne.de> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
>
>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>
>>> Victor Yodaiken <victor.yodaiken@gmail.com> schrieb:
>>>
>>>> Can you cast a pointer to a different type? Sure.
>>>>
>>>> Can you dereference it?
>>>
>>> No.
>>
>> This statement is wrong, or at best much overstated.
>
> You are right there.
>
> However, modern compiler technology offers an alternative:
> memcpy is now very well optimized, and what appears to
> be moving data around is in fact optimized away.

It is of course possible for an implementation to give a
well-defined semantics to dereferencing type-converted pointers,
and to produce code that carries out those semantics, whether by
using memcpy() or some other means. The -fno-strict-aliasing
option in gcc is provided for doing exactly that. The point is
that some of these cases obey C's effective type rules and are
defined by the C standard, and such cases must be accommodated by
all conforming implementations, whereas other cases are optional
and left to each implementation to handle in any way they see
fit (and one way of handling them is a -fno-strict-aliasing
option like what gcc provides).

> AFAIK, this is then implementation-defined behavior, not
> undefined behavior.

It looks like you are confused about the meaning of these two
terms. A particular piece of code has implementation-defined
behavior only if the C standard specifically says that such
situations are implementation-defined. Any case that the C
standard puts under the heading of undefined behavior is still
undefined behavior regardless of whether an implementation
chooses to give a well-defined semantics to such cases (as for
example -fwrapv or -fno-strict-aliasing in gcc do). Each
implementation /must/ define all cases of implementation-defined
behavior (and document the choice in each case). For undefined
behaviors, each implementation /may/ choose to define each case
in any way it considers appropriate, or it may elect to give no
guarantees whatsoever for some or all cases. In practice I think
all implementations define some cases of undefined behavior
(often not documenting the choices) and leave some other cases
completely without guarantees as far as what might happen. No
matter which cases are given guarantees and which are not doesn't
interfere with the implementation being a conforming
implementation.

On 10/16/2021 7:52 AM, Ivan Godard wrote:
> On 10/16/2021 7:21 AM, Stephen Fuld wrote:
>> On 10/16/2021 3:49 AM, Thomas Koenig wrote:
>>> MitchAlsup <MitchAlsup@aol.com> schrieb:
>>>
>>>> This, however, is a NG devoted to architectures that can run C and
>>>> all sorts of other languages. Architectures and implementations of
>>>> those architectures.
>>>>
>>>> It should a design goal of any architect to provide an efficient and
>>>> straightforward instruction set that enables compilers to produce
>>>> small, efficient, correct applications from a given set of source code.
>>>
>>> You are, of course, correct.
>>>
>>> There is another goal, which is to have zero or low overhead for
>>> error checking.  If I may quote C.A.R. Hoare:
>>>
>>> # Finally, it is absurd to make elaborate security checks on debugging
>>> # runs, when no trust is put in the results, and then remove them
>>> # in production runs, when an erroneous result could be expensive
>>> # or disastrous.  What would we think of a sailing enthusiast who
>>> # wears his lifejacket when training on dry land, but takes it off
>>> # as soon as he goes to sea?
>>>
>>> The reason for this is that some languages like C make error
>>> checking very difficult (for example, finding out the valid range
>>> for pointer arithmetic in a function needs information from the
>>> caller, which is not available via the standard language).
>>>
>>> There are languages where the necessary info is provided, Ada
>>> and Fortran among them.  However, that there is a rather large
>>> overhead in code size and, more importantly, execution time.
>>> IIRC (but correct me if I'm wrong) even gnat comes which range
>>> checking switched off by default.
>>>
>>> To extend the metaphor above, the lifejacket comes combined with
>>> a sea anchor, which is not good if you want to go somewhere.
>>>
>>> There are a couple of notorious bug classes which surface again
>>> and again.  Buffer overruns are a classic, as are "use after free"
>>> errors and signed overruns.
>>>
>>> First, buffer overruns.  Compilers need to become better at moving
>>> checking code out of loops.  One idea that could help (with compiler
>>> support, of course) is to define a valid range for a register
>>> (which could hold an address to an array or an index) to be in
>>> for a certain amount of instructions, trapping if it is outside.
>>> Maybe a few "range registers" with a way to associate a certain
>>> register with them, to allow spill / restore.
>>>
>>> Signed overruns - the very topic we are discussing here.  Integer
>>> arithmetic could (optionally) trap on a 64-bit overflow, a 32-bit
>>> overflow, a 16-bit overflow and an 8-bit overflow.
>>>
>>> Use after free - much more difficult.  It might be possible to
>>> have a hardware list of "poisoned" address ranges from which it is
>>> not permitted to load.  Very expensive (comparable to
>>> cache) and would probably cache only the most recently freed
>>> memory blocks.  Not sure if this is worth it.
>>>
>>> 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.
>
> Signed overflow does not require delayed check; it requires control of
> delivery of the checked event.

Agreed. I may not have been clear, but I think what I was proposing
(adding the check instructions if needed) does that.

> Not everything is vanilla C;

My personal bias is showing, but Thank Goodness!

> 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.

If you don't want the check, then don't generate the check instructions.
My only point was that the check instructions, if required, cost less
now than they used to, because the check can be done in parallel with
the subsequent instructions, as long as those subsequent instructions
don't commit before the check is passed.

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

Thomas Koenig <tkoenig@netcologne.de> writes:
[bounds checking]
>There are languages where the necessary info is provided, Ada
>and Fortran among them. However, that there is a rather large
>overhead in code size and, more importantly, execution time.

Please support your claim with empirical results.

>Compilers need to become better at moving
>checking code out of loops.

Again, support needed. My impression is that the Cousots solved this
problem pretty well in the 1970, and for the common case their
solution is good enough. And it's not clear that much can be done for
the other cases.

>Signed overruns - the very topic we are discussing here. Integer
>arithmetic could (optionally) trap on a 64-bit overflow, a 32-bit
>overflow, a 16-bit overflow and an 8-bit overflow.

Consider:

signed char a=127;
signed char b=127;
signed char c;
c=a+b;

The addition is defined in C. Maybe the narrowing of the result in
the assignment is undefined, C standards lawyers will know.

But of course, the major question is who wants this? Who uses -ftrapv
on MIPS and Alpha which have such instructions (for 32 bits and 64
bits, relevant for their I32LP64 C).

>Use after free - much more difficult. It might be possible to
>have a hardware list of "poisoned" address ranges from which it is
>not permitted to load. Very expensive (comparable to
>cache) and would probably cache only the most recently freed
>memory blocks. Not sure if this is worth it.

If you have NaT bits associated with the memory, you could fill the
free()d memory with NaTs.

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

On Friday, October 15, 2021 at 7:07:36 PM UTC+3, Stephen Fuld wrote:
> On 10/15/2021 8:38 AM, David Brown wrote:
>
> snip
> > There are lots of things that are missing in C's model. Really, I think
> > the fuss about flat address spaces, aliasing pointers, integer overflow,
> > and so on, are all peanuts compared to the /big/ missing point - C has
> > no concept of timing. For a lot of low level or embedded code, being
> > able to specify timing constraints, requirements or restrictions in the
> > programming language would be /hugely/ more useful than knowing that you
> > can safely compare two random addresses (a requirement I have never
> > needed or considered at all useful - and one that can easily be handled
> > by casting to uintptr_t if you actually needed it).
> Can you expound on what kind of syntax and semantics you want a language
> to have for the timing related stuff? Since the compiler, much less
> than language, doesn't know about the speed of the eventual hardware the
> program will be run on, I don't see how it can specify timing.
>
>
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

A war story from ~2 years ago (I am not sure if details of code are correct, but sure about principle):

#define TIME_VAL (*(volatile uint32_t*)0x12345608))
#define ACTION_REG (*(volatile uint32_t*)0x43215604))

void foo(int moo, int arg, uint32_t t0, uint32_t dt)
{ uint32_t bar;
if (moo)
bar = 0.42 * arg - 11.3;
else
bar = 0.43 * arg + 11.7;

if (moo) {
while (TIME_VAL-t0 < dt);
}
ACTION_REG = bar;
}

TIME_VAL is a hardware register that contains free running counter incrementing every CPU clock.
A write to ACTION_REG initiates important hardware activity.
Execution environment - ARM Cortex-M3 - based micro-controller.
M3 core has no caches and in our case all interrupts were disabled, so we expected very consistent and very small time variation
between designated time and action.
I practice we observed not very consistent and absurdly large delay of several microsecons.

It turned out that smart compiler (yes, it was gcc -O2, but I believe that other compilers are not immune although we didn't observe the problem with IAR)
changed our code to something like that:
void foo(int moo, int arg, uint32_t t0, uint32_t dt)
{ uint32_t bar;
if (moo) {
while (TIME_VAL-t0 < dt);
bar = 0.42 * arg - 11.3;
} else {
bar = 0.43 * arg + 11.7;
}
ACTION_REG = bar;
} For those, not familiar with Cortex-M, these cores have no double-precision hardware, so calculation of bar indeed takes few uSec and that's the reason why code was structured to do it outside of time-critical section.
But, as mentioned above, C language has no concept of time or time-criticality.
IIRC, Ada is no better and Fortran is certainly no better.

On Saturday, October 16, 2021 at 5:33:32 PM UTC+3, Anton Ertl wrote:
> MitchAlsup <Mitch...@aol.com> writes:
> >What could be changed in the FETCH unit to make those C un-specifications
> >better?
> ><
> >What could be changed in the DECODE unit to make those C un-specifications
> >better?
>
> I don't think that C is affected by that.
>
> >What could be changed in the EXECUTE unit to make those C un-specifications
> >better?
>
> What do you mean with "the EXECUTE unit"? There seem to be a lot of
> functional units.
>
> >What could be changed in the AGEN unit to make those C un-specifications
> >better?
> ><
> >What could be changed in the LDALIGN unit to make those C un-specifications
> >better?
>
> One interesting aspect here is that Intel has always supported
> unaligned accesses (including specifying calling conventions that made
> setting the alignment bit (that they also provided) a no-go). Then
> they introduced SSE and required 16-byte (not element) alignment for
> load-op and RMW instructions

Nitpick - load-op rather than RMW.
There are no RMW in SSE instruction set (same as x87, AVX and AVX512).

> as well was for some pure load and store
> instructions, but at least they provided unaligned variants of the
> pure instructions. AMD fixed that mistake by Intel by providing a
> flag (unfortunately Intel did not pick that up). Intel finally fixed
> that mistake with AVX, where the load-op and RMW instructions do not
> require alignment. But Intel provided both variants of pure
> instructions.
>
> And of course the gcc people select the variant that requires
> alignment in their auto-vectorizer, breaking previously working code.
>
> What could be changed? Intel and AMD could make the instructions that
> require alignment slower than the ones that do not. It's unclear if
> that would help, see
> <http://www.complang.tuwien.ac.at/anton/autovectors/> for some reason
> to doubt this.
>
> >What could be changed in the MEMORY-Model to make those C un-specifications
> >better?
>
> I don't know if C already has a memory model for shared memory, but
> implementing sequential consistency in hardware at no extra cost for
> non-shared accesses could make it nicer to use. Basically one would
> ask for sequential consistency and forget about all the weaker
> options.
>
> >Just what pieces of HW could be made better enough to make your discussion of
> >C (un)specified behavior take 10% as long as it has already taken ?
>
> It's true. The problem is not current hardware, but hardware from the
> 1960s that, e.g., did not have 2s-complement, which gave rise to the
> signed integer undefined behaviour on overflow. And now that compiler
> writers think that this gives them some edge, they will never let go
> of this undefined behaviour until C vanishes in oblivion.
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

On 2021-10-16 15:27, Victor Yodaiken wrote:
> On Saturday, October 16, 2021 at 4:19:11 AM UTC-5, Thomas Koenig
> wrote:
>> Victor Yodaiken <victor....@gmail.com> schrieb:
>>> On Friday, October 15, 2021 at 10:38:52 AM UTC-5, David Brown
>>> wrote:
>>>> On 14/10/2021 21:34, Stefan Monnier wrote:
>>>>> David Brown [2021-10-14 16:24:40] wrote:
>>>
>>>> High level languages - and C is a high level language - are
>>>> defined in terms of abstract machines, not the hardware.
>>>
>>> That is certainly a view, but it's more than debatable.
>> Says so in the standard, which I quoted.
>
> Cat: while( (n = read(0,buf))>0)write(1,buf,n);
>
> Neither read nor write are defined in the C Standard, in fact calling
> them is C-Standard UB.

That is a ridiculous and unwarranted extension of the concept of
"udefined behaviour" in the C Standard. You make this extension only to
support your incorrect claim that useful C programs must include
undefined behaviour in the C Standard sense.

Of course many useful C programs have effects that are not defined in
the C Standard, but that is because those effects are *outside the C VM*
and thus not in scope for the C Standard.

> There is no specification of what happens in the abstract machine on
> those calls. QED.

Not QED. If "read" and "write" are defined to have "C interface" and be
compatible with a C caller, as you surely intended, it seems to me that
the C Standard *does* define their possible effects on the C virtual
machine:

- The call of "read" executes whatever computation is implemented in
"read" and then returns a value of type "int", which is assigned to "n".
The effect of the computation in "read" on the C VM can include *only*:

o reading or writing the data pointed to by "buf" or by any
pointer value calculated by offsetting or indexing "buf", as long as
that stays within the same array (otherwise we have real undefined
behaviour in the C Standard sense),

o reading or writing any globally visible variables of the calling
program, including pointer variables, thus possibly reading or writing
the pointed-to data, with the same conditions as for "buf",

o possibly calling any globally visible function of the calling
program.

Of course the actual OS "read", which I assume you intended, has only a
small subset of those effects on the C VM, as explained in "man read".

- The call of "write" is entirely analogous.

> The distinctive feature of the C Standard is that it depends so much
> on what it purposefully does not define.

The C Standard purposefully does not define effects external to the C
VM. But those effects are not "undefined behaviour" in the C Standard
sense, and compilers do not use the undefinedness of those effects to
optimize code.

On Saturday, October 16, 2021 at 12:22:03 PM UTC-5, Niklas Holsti wrote:
> On 2021-10-16 15:27, Victor Yodaiken wrote:
> > On Saturday, October 16, 2021 at 4:19:11 AM UTC-5, Thomas Koenig
> > wrote:
> >> Victor Yodaiken <victor....@gmail.com> schrieb:
> >>> On Friday, October 15, 2021 at 10:38:52 AM UTC-5, David Brown
> >>> wrote:
> >>>> On 14/10/2021 21:34, Stefan Monnier wrote:
> >>>>> David Brown [2021-10-14 16:24:40] wrote:
> >>>
> >>>> High level languages - and C is a high level language - are
> >>>> defined in terms of abstract machines, not the hardware.
> >>>
> >>> That is certainly a view, but it's more than debatable.
> >> Says so in the standard, which I quoted.
> >
> > Cat: while( (n = read(0,buf))>0)write(1,buf,n);
> >
> > Neither read nor write are defined in the C Standard, in fact calling
> > them is C-Standard UB.
> That is a ridiculous and unwarranted extension of the concept of
> "udefined behaviour" in the C Standard.

"Undefined behavior is otherwise indicated in this International
Standard by the words “undefined behavior” or by the omission of any explicit definition of behavior.
There is no difference in emphasis among these three; they all describe “behavior that is undefined” "

>You make this extension only to
> support your incorrect claim that useful C programs must include
> undefined behaviour in the C Standard sense.
>

My motivations don't affect the validity of my assertions.

> Of course many useful C programs have effects that are not defined in
> the C Standard, but that is because those effects are *outside the C VM*
> and thus not in scope for the C Standard.

Undefined behavior is otherwise indicated in this International
Standard by the words “undefined behavior” or by the omission of any explicit definition of behavior.
There is no difference in emphasis among these three; they all describe “behavior that is undefined”

\
> > The distinctive feature of the C Standard is that it depends so much
> > on what it purposefully does not define.
> The C Standard purposefully does not define effects external to the C
> VM. But those effects are not "undefined behaviour" in the C Standard
> sense, and compilers do not use the undefinedness of those effects to
> optimize code.

Compilers do not use the undefinedness of ending a file without a new-line
to optimize either. It doesn't make a difference how the compilers use or
don't use UB - it is simply behavior that is not defined by the standard.

UB:
A nonempty source file does not end in a new-line character which is not immediately preceded
by a backslash character or ends in a partial preprocessing token or comment (5.1.1.2).

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> writes:
> [bounds checking]
>>There are languages where the necessary info is provided, Ada
>>and Fortran among them. However, that there is a rather large
>>overhead in code size and, more importantly, execution time.
>
> Please support your claim with empirical results.

$ cat mm.f90
module mm
implicit none
contains
subroutine do_mm (a,b,c)
real, dimension(:,:), intent(in) :: a, b
real, dimension(:,:), intent(out) :: c
integer :: i, j, k
do j=1, size(b,2)
do k=1, size(a,2)
do i=1, size(a,1)
c(i,j) = c(i,j) + a(i,k) * b(k,j)
end do
end do
end do
end subroutine do_mm
end module mm

$ cat main.f90
program main
use mm
implicit none
real, dimension(:,:), allocatable :: a, b, c
character (len=20) :: line
real :: t1, t2
allocate (a(1000,1000), b(1000,1000), c(1000,1000))
call random_number (a)
call random_number (b)
call cpu_time (t1)
call do_mm(a,b,c)
call cpu_time (t2)
write (unit=line,fmt=*) c(1,1)
write (*,*) t2-t1
end program main
$ gfortran -O3 mm.f90 main.f90
$ ./a.out
9.59559977E-02
$ gfortran -fcheck=bounds -O3 mm.f90 main.f90
$ ./a.out
0.563069999

Is a factor of 5.8 significant enough for you?
>
>>Compilers need to become better at moving
>>checking code out of loops.
>
> Again, support needed.

See above.

On 2021-10-15 19:07, Stephen Fuld wrote:
> On 10/15/2021 8:38 AM, David Brown wrote:
>
> snip
>
>> There are lots of things that are missing in C's model.  Really, I think
>> the fuss about flat address spaces, aliasing pointers, integer overflow,
>> and so on, are all peanuts compared to the /big/ missing point - C has
>> no concept of timing.  For a lot of low level or embedded code, being
>> able to specify timing constraints, requirements or restrictions in the
>> programming language would be /hugely/ more useful than knowing that you
>> can safely compare two random addresses (a requirement I have never
>> needed or considered at all useful - and one that can easily be handled
>> by casting to uintptr_t if you actually needed it).
>
> Can you expound on what kind of syntax and semantics you want a language
> to have for the timing related stuff?

I believe there have been languages, or language proposals, where
real-time constraints can be defined in the source. The term "Real-Time
Euclid" comes to mind, but my search found only pay-walled references,
some in the IEEE Digital Library.

> Since the compiler, much less than language, doesn't know about the
> speed of the eventual hardware the program will be run on, I don't
> see how it can specify timing.

Some compilers do know a lot about the target HW and its timing, and use
this knowledge for selecting optimizations, but the precision of this
knowledge depends on the predictability of the HW timing. Some machines,
such as the Mill and PRET and the XMOS machines, are designed to have
predictable, deterministic timing (as far as possible -- of course
caches and such will not be entirely predictable). Small
microcontrollers for embedded systems used to have very predictable
timing (in the absence of caches and such).

It is also possible to connect a compiler to a WCET analyzer. The WCET
analyzer can guide the compiler's optimizations, for example to focus on
the code in a high-rate branch, and can confirm or disconfirm timing
constraints given in the source code.

For a multi-threaded program one would also have to involve a
schedulability analyzer, and I believe that was done in the Real-Time
Euclid case (but, I believe, without a WCET analyzer).

John Levine <johnl@taugh.com> writes:

> According to Branimir Maksimovic <branimir.maksimovic@icloud.com>:
>
>>> Fortran has evolved. Look at current Fortran, not at something from over
>>> half a century ago.
>>
>> Well, it's not FORTRAN anymore then :P
>
> As my thesis advisor Alan Perlis said when I was a student in the
> 1970s, I don't know what language people will be using in the year
> 2000, but it will be called Fortran.

I wouldn't be surprised if Alan Perlis said this, but I think it
was said originally by Tony Hoare. (Disclaimer: my memory is
known to be faulty at times, and I have made no attempt to find
sources to support my unreliable memory.)

Thomas Koenig <tkoenig@netcologne.de> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
>
>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>
>> [...]
>>
>>> There is also the restriction on the complexity, which makes
>>>
>>> #! /bin/sh
>>> echo "Program to complex, aborting" 1>&2
>>>
>>> a valid C compiler according to the standard.
>>
>> Not true. Feel free to ask in comp.std.c if you want
>> to understand why.
>
> I'd be interested, but why not have it out in this forum
> where the discussion started out?

Several reasons, but the most important one is this part
of the discussion has strayed far enough outside the local
topicality bounds that I feel obliged to redirect it.

Victor Yodaiken <victor.yodaiken@gmail.com> writes:

> On Friday, October 15, 2021 at 10:11:49 AM UTC-5, David Brown wrote:
>
>> In C, some people think wrapping signed integer overflow is a perfectly
>> reasonable choice of behaviour - that does not make it defined behaviour
>> in C, and it does not stop programs that rely on such behaviour from
>> being incorrect and program errors.
>
> When gcc/clang are used with the fwrapv flag, they define integer
> overflow to wrap as they are permitted to do by the C standard.
> Programs that rely on that behavior are not incorrect.
>
> There is nothing in the C standard that privileges one
> interpretation of C UB over another one.

Right.

On 2021-10-16 20:03, Michael S wrote:
> On Friday, October 15, 2021 at 7:07:36 PM UTC+3, Stephen Fuld wrote:
>> On 10/15/2021 8:38 AM, David Brown wrote:
>>
>> snip
>>> There are lots of things that are missing in C's model. Really, I think
>>> the fuss about flat address spaces, aliasing pointers, integer overflow,
>>> and so on, are all peanuts compared to the /big/ missing point - C has
>>> no concept of timing. For a lot of low level or embedded code, being
>>> able to specify timing constraints, requirements or restrictions in the
>>> programming language would be /hugely/ more useful than knowing that you
>>> can safely compare two random addresses (a requirement I have never
>>> needed or considered at all useful - and one that can easily be handled
>>> by casting to uintptr_t if you actually needed it).
>>
>> Can you expound on what kind of syntax and semantics you want a language
>> to have for the timing related stuff? Since the compiler, much less
>> than language, doesn't know about the speed of the eventual hardware the
>> program will be run on, I don't see how it can specify timing.
>>
>>
>> --
>> - Stephen Fuld
>> (e-mail address disguised to prevent spam)
>
> A war story from ~2 years ago (I am not sure if details of code are
> correct, but sure about principle):
>
> #define TIME_VAL (*(volatile uint32_t*)0x12345608))
> #define ACTION_REG (*(volatile uint32_t*)0x43215604))
>
> void foo(int moo, int arg, uint32_t t0, uint32_t dt)
> {
> uint32_t bar;
> if (moo)
> bar = 0.42 * arg - 11.3;
> else
> bar = 0.43 * arg + 11.7;
>
> if (moo) {
> while (TIME_VAL-t0 < dt);
> }
> ACTION_REG = bar;
> }
>
> TIME_VAL is a hardware register that contains free running counter
> incrementing every CPU clock.
> A write to ACTION_REG initiates important hardware activity.
> Execution environment - ARM Cortex-M3 - based micro-controller.
> M3 core has no caches and in our case all interrupts were disabled,
> so we expected very consistent and very small time variation
> between designated time and action.> I practice we observed not very
> consistent and absurdly large delay of several microsecons. >
> It turned out that smart compiler (yes, it was gcc -O2, but I
> believe that other compilers are not immune although we didn't
> observe the problem with IAR) changed our code to something like
> that: >
> void foo(int moo, int arg, uint32_t t0, uint32_t dt)
> {
> uint32_t bar;
> if (moo) {
> while (TIME_VAL-t0 < dt);
> bar = 0.42 * arg - 11.3;
> } else {
> bar = 0.43 * arg + 11.7;
> }
> ACTION_REG = bar;
> }

That is of course an allowed re-ordering of the code. A nice reminder
for us all to be careful and aware of such things.

> For those, not familiar with Cortex-M, these cores have no
> double-precision hardware,

(As an aside: was it intended to use double precision? Or was that a
mistake due to omitted "f" suffixes on the floating literals?)

> so calculation of bar indeed takes few uSec and that's the reason why
> code was structured to do it outside of time-critical section.

As I think has been commented recently here, C can be forced to obey the
source-code order by good use of "volatile". Making "bar" volatile
should have solved this problem.

How did you solve it?

> But, as mentioned above, C language has no concept of time or
> time-criticality. IIRC, Ada is no better

Ada at least has the concept of task priorities, which is certainly an
aspect of time-criticality. But within a single task, the same kind of
reordering as in the above example could happen in Ada too. And the
solution is the same: use "volatile".

Victor Yodaiken <victor.yodaiken@gmail.com> writes:

> [...] My first point was that it is fundamentally incorrect to
> identify undefined behavior in that sense as a C-Standard
> programming error.

Unless there is some sort of additional context, right. It might
indicate a programming error or it might be just fine, but which
is the case depends on context from where the question is asked.

> My second point is that that the C standard, at the very least,
> does not require compilers to use C Standard undefined behavior
> as opportunity for "optimization" or program error or similar.

Right.

Thomas Koenig wrote:
> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>> Thomas Koenig <tkoenig@netcologne.de> writes:
>> [bounds checking]
>>> There are languages where the necessary info is provided, Ada
>>> and Fortran among them. However, that there is a rather large
>>> overhead in code size and, more importantly, execution time.
>> Please support your claim with empirical results.
>
> $ cat mm.f90
> module mm
> implicit none
> contains
> subroutine do_mm (a,b,c)
> real, dimension(:,:), intent(in) :: a, b
> real, dimension(:,:), intent(out) :: c
> integer :: i, j, k
> do j=1, size(b,2)
> do k=1, size(a,2)
> do i=1, size(a,1)
> c(i,j) = c(i,j) + a(i,k) * b(k,j)
> end do
> end do
> end do
> end subroutine do_mm
> end module mm
>
> $ cat main.f90
> program main
> use mm
> implicit none
> real, dimension(:,:), allocatable :: a, b, c
> character (len=20) :: line
> real :: t1, t2
> allocate (a(1000,1000), b(1000,1000), c(1000,1000))
> call random_number (a)
> call random_number (b)
> call cpu_time (t1)
> call do_mm(a,b,c)
> call cpu_time (t2)
> write (unit=line,fmt=*) c(1,1)
> write (*,*) t2-t1
> end program main
> $ gfortran -O3 mm.f90 main.f90
> $ ./a.out
> 9.59559977E-02
> $ gfortran -fcheck=bounds -O3 mm.f90 main.f90
> $ ./a.out
> 0.563069999
>
> Is a factor of 5.8 significant enough for you?
>>> Compilers need to become better at moving
>>> checking code out of loops.
>> Again, support needed.
>
> See above.

I'd like to see the asm for do_mm.
Because the range for each loop variable is deterministic
from the size of the passed arrays.
It should be able to do just 3 bounds checks before loop start,
compare range of k to size (b,1), range of i to size(c,1),
range of j to size(c,2). then loop without index checks.
Other index checks are unnecessary because range of k is
derived from size(b,2), range of k from size(a,2), range of i from size(a,1).

While the loop index variables may change, their range is loop invariant.
That makes the index bounds checks hoistable as loop invariants.

Victor Yodaiken <victor.yodaiken@gmail.com> writes:

> On Thursday, October 14, 2021 at 7:09:16 PM UTC-5, Tim Rentsch wrote:
>
>> Victor Yodaiken writes:
>>
>>> [...] GCC says that you can use unions for type puns (which I find
>>> awkward) although the standard does not.
>>
>> The C standard says very plainly that type punning may be achieved
>> by means of union member access. Quoting 6.5.2.3, paragraph 3,
>> footnote 95, first sentence, from N1570
>>
>> If the member used to read the contents of a union object is
>> not the same as the member last used to store a value in the
>> object, the appropriate part of the object representation of
>> the value is reinterpreted as an object representation in the
>> new type as described in 6.2.6 (a process sometimes called
>> "type punning").
>
> In a non-normative footenote.

That observation doesn't change the truth of my statement, nor
that what the footnote says follows from normative text in the C
standard, nor more importantly that implementors accept what the
footnote says accurately reflects what the standard requires.

On 10/16/2021 8:18 AM, Stephen Fuld wrote:
> On 10/16/2021 7:52 AM, Ivan Godard wrote:
>> On 10/16/2021 7:21 AM, Stephen Fuld wrote:
>>> On 10/16/2021 3:49 AM, Thomas Koenig wrote:
>>>> MitchAlsup <MitchAlsup@aol.com> schrieb:
>>>>
>>>>> This, however, is a NG devoted to architectures that can run C and
>>>>> all sorts of other languages. Architectures and implementations of
>>>>> those architectures.
>>>>>
>>>>> It should a design goal of any architect to provide an efficient and
>>>>> straightforward instruction set that enables compilers to produce
>>>>> small, efficient, correct applications from a given set of source
>>>>> code.
>>>>
>>>> You are, of course, correct.
>>>>
>>>> There is another goal, which is to have zero or low overhead for
>>>> error checking.  If I may quote C.A.R. Hoare:
>>>>
>>>> # Finally, it is absurd to make elaborate security checks on debugging
>>>> # runs, when no trust is put in the results, and then remove them
>>>> # in production runs, when an erroneous result could be expensive
>>>> # or disastrous.  What would we think of a sailing enthusiast who
>>>> # wears his lifejacket when training on dry land, but takes it off
>>>> # as soon as he goes to sea?
>>>>
>>>> The reason for this is that some languages like C make error
>>>> checking very difficult (for example, finding out the valid range
>>>> for pointer arithmetic in a function needs information from the
>>>> caller, which is not available via the standard language).
>>>>
>>>> There are languages where the necessary info is provided, Ada
>>>> and Fortran among them.  However, that there is a rather large
>>>> overhead in code size and, more importantly, execution time.
>>>> IIRC (but correct me if I'm wrong) even gnat comes which range
>>>> checking switched off by default.
>>>>
>>>> To extend the metaphor above, the lifejacket comes combined with
>>>> a sea anchor, which is not good if you want to go somewhere.
>>>>
>>>> There are a couple of notorious bug classes which surface again
>>>> and again.  Buffer overruns are a classic, as are "use after free"
>>>> errors and signed overruns.
>>>>
>>>> First, buffer overruns.  Compilers need to become better at moving
>>>> checking code out of loops.  One idea that could help (with compiler
>>>> support, of course) is to define a valid range for a register
>>>> (which could hold an address to an array or an index) to be in
>>>> for a certain amount of instructions, trapping if it is outside.
>>>> Maybe a few "range registers" with a way to associate a certain
>>>> register with them, to allow spill / restore.
>>>>
>>>> Signed overruns - the very topic we are discussing here.  Integer
>>>> arithmetic could (optionally) trap on a 64-bit overflow, a 32-bit
>>>> overflow, a 16-bit overflow and an 8-bit overflow.
>>>>
>>>> Use after free - much more difficult.  It might be possible to
>>>> have a hardware list of "poisoned" address ranges from which it is
>>>> not permitted to load.  Very expensive (comparable to
>>>> cache) and would probably cache only the most recently freed
>>>> memory blocks.  Not sure if this is worth it.
>>>>
>>>> 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.
>>
>> Signed overflow does not require delayed check; it requires control of
>> delivery of the checked event.
>
> Agreed.  I may not have been clear, but I think what I was proposing
> (adding the check instructions if needed) does that.
>
>> Not everything is vanilla C;
>
> My personal bias is showing, but Thank Goodness!
>
>> 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.
>
> If you don't want the check, then don't generate the check instructions.
>  My only point was that the check instructions, if required, cost less
> now than they used to, because the check can be done in parallel with
> the subsequent instructions, as long as those subsequent instructions
> don't commit before the check is passed.

I differ, and would say: as long as no instructions are committed which
depend upon the success of the check and irretrievably alter system state.

On 10/16/2021 9:07 AM, Anton Ertl wrote:
> Thomas Koenig <tkoenig@netcologne.de> writes:
> [bounds checking]
>> There are languages where the necessary info is provided, Ada
>> and Fortran among them. However, that there is a rather large
>> overhead in code size and, more importantly, execution time.
>
> Please support your claim with empirical results.
>
>> Compilers need to become better at moving
>> checking code out of loops.
>
> Again, support needed. My impression is that the Cousots solved this
> problem pretty well in the 1970, and for the common case their
> solution is good enough. And it's not clear that much can be done for
> the other cases.
>
>> Signed overruns - the very topic we are discussing here. Integer
>> arithmetic could (optionally) trap on a 64-bit overflow, a 32-bit
>> overflow, a 16-bit overflow and an 8-bit overflow.
>
> Consider:
>
> signed char a=127;
> signed char b=127;
> signed char c;
> c=a+b;
>
> The addition is defined in C. Maybe the narrowing of the result in
> the assignment is undefined, C standards lawyers will know.
>
> But of course, the major question is who wants this? Who uses -ftrapv
> on MIPS and Alpha which have such instructions (for 32 bits and 64
> bits, relevant for their I32LP64 C).
>
>> Use after free - much more difficult. It might be possible to
>> have a hardware list of "poisoned" address ranges from which it is
>> not permitted to load. Very expensive (comparable to
>> cache) and would probably cache only the most recently freed
>> memory blocks. Not sure if this is worth it.
>
> If you have NaT bits associated with the memory, you could fill the
> free()d memory with NaTs.

I would love to have NaT bits (NaR in our terminology) associated with
memory. It's certainly doable, but not economically feasible IMO, unless
you are Samsung.