On 2021-10-14, Thomas Koenig <tkoenig@netcologne.de> wrote:
> Branimir Maksimovic <branimir.maksimovic@icloud.com> schrieb:
>
>> Fortran is pre structured era, spagetti code.
>
> Your knowledge seems to be stuck in the 1980s.
>
> To see what was available in Fortran 95,
> around 25 years ago, you could try reading
> https://en.wikipedia.org/wiki/Fortran_95_language_features
So what do you recommend? Fortran or ADA?

--

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

On 2021-10-14, Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
> On 10/14/2021 4:05 AM, Branimir Maksimovic wrote:
>
> snip
>
>
>> Fortran is pre structured era, spagetti code. Good for
>> arrays, not mutch for anything else :P
>> Good luck with network code or parsing with FORTRAN :P
>
> Sort of. FORTRAN was defined pre structured era, but it added
> structuring features decades ago.
>
> As for parsing, in the late 1970s, I used AMDASM, an assembler for 2901
> bit sliced CPUs that was written in FORTRAN. It worked fine.
>
>
>
Good to know. Thanks!

--

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

On 2021-10-14, MitchAlsup <MitchAlsup@aol.com> wrote:
> On Thursday, October 14, 2021 at 6:05:22 AM UTC-5, Branimir Maksimovic wrote:
>> On 2021-10-14, Thomas Koenig <tko...@netcologne.de> wrote:
>> > Victor Yodaiken <victor....@gmail.com> schrieb:
>> >
>> >> The paper really focuses on the example of alias optimizations
>> >> and Dennis Ritchie's strong - and prescient warnings.
>> >
>> > Dennis Ritchie was warning about a specific feature which did
>> > not make it into the language.
>> >
>> > [...]
>> >
>> >> Again, I don't have to believe that Ritchie was always right
>> >> about everything to consider him one of the most brilliant CS
>> >> researchers/programmers and to find his arguments on this issue
>> >> strong. And I don't even have to oppose all alias analysis -
>> >> in fact, I think, the type based approach taken by ISO reduces
>> >> the expressive range of the language, creates complexity and
>> >> murky semantics, AND leaves a lot of alias based optimization on
>> >> the table.
>> >
>> > One of the design faults of C is the overuse of pointers,
>> > specifically for array access (including pointer arithmetic),
>> > dynamic memory allocation and for argument passing. While a
>> > good design decision for the 1970s with limited resources for a
>> > compiler, the very first high-level programming language, FORTRAN,
>> > had already handled parts of this better.
>> >
>> > Now, consider:
>> >
>> > float *fp;
>> > int *fp;
>> > float a;
>> >
>> > /* ... */
>> >
>> > *fp = something;
>> > *ip = something_else;
>> > printf ("%f", *fp);
>> >
>> > Assume that the value of *fp is held in a register. Should the
>> > store to *ip make a reload of fp necessary before the printf?
>> >
>> >> And part of the reason is because sound alias analysis is much
>> >> *harder* for compilers than alias assumptions.
>> >
>> > Which is why I like the Fortran model much better. In Fortran,
>> >
>> > - if you have overlapping dummy arguments, you cannot store
>> > a value through one and access it through another one
>> > (which is rarely checked, unfortunately)
>> >
>> > - variables which can be a target of a pointer must be
>> > marked TARGET
>> >
>> > - you have allocatable variables (which are automatically
>> > deallocated when they go out of scope), which are not
>> > TARGETs and which cannot alias anything else
>> >
>> > - Pointers can also point to multi-dimensional arrays
>> >
>> > (and teaching the somewhat C-centric gcc about optimizations
>> > possible according to the Fortran language definition is an
>> > ongoing process).
>> >
>> >> Since you bring it up, for me the way C originally handled
>> >> integer overflow was sloppy and sometimes dangerous - it was an
>> >> engineering tradeoff made to make fast code and simple compilation.
>> >> BUT the ISO-C approach is mathematically incoherent and even more
>> >> dangerous - because semantics is unpredictable.
>> >
>> > Signed integer overflow is an error, period (the same in
>> > Fortran as in C).
>> >
>> >> Ironically, as C compilers muddied int arithmetic, processors
>> >> became much better about native signed arithmetic. Mod 2^k 2s
>> >> complement, which is native on the vast majority of modern
>> >> processors is mathematically coherent even if it is hard to
>> >> work with.
>> >
>> > Very hard, and a source of errors...
>> >
>> >> But what we have in ISO C makes arithmetic depend on vagaries
>> >> of the optimizer and produces paradoxes.
>> >
>> > Ah, no. It means that an erroneous program gets random results,
>> > which is not surprising. Would you also like to prosrcribe results
>> > for array overruns? Ada does so, and both it and Fortran are
>> > better languages if you want to have a lower error rate than for C.
>> >
>> > You will not have much luck changing C.
>> Fortran is pre structured era, spagetti code. Good for
>> arrays, not mutch for anything else :P
>> Good luck with network code or parsing with FORTRAN :P
><
> I lead a team that built a FORTRAN runtime library using nothing other
> than FORTRAN.
Great! Thanks!

--

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

On 14/10/2021 20:20, Victor Yodaiken wrote:
> "Undefined behavior" does not mean "programming error" and never
> has. One meaning is just something not specified explicitly in the
> standard.

"Undefined behaviour" in the C standard means the C standard does not
define the behaviour. It really is that simple.

The C standard provides /part/ of the description of how a particular
piece of C source code will act when you run the final binary. The
documentation (in theory - though we all know how bad software
documentation can be!) for the C compiler provides additional semantics
covering everything that the C standard describes as
"implementation-dependent". Usually the compiler documentation will
delegate some of that to the target ABI or information about the OS
and/or the processor. The C implementation might also define some
things that the C standard left undefined - it is, for example, free to
say what happens on integer overflow. It is also free to implement
extensions that do not conflict with the standard - when gcc implements
"__builtin_types_compatible_p", it is implementing behaviour for
something that is undefined behaviour (by omission of a definition) in
the C standard.

At this stage, there is still plenty that is undefined. In particular,
calls to functions outside the C standard library may not be defined.
That is up to the documentation or specifications for those functions.
And some of their behaviour will often be undefined - if function "int
foo(int x)" says it expects "x" to be between 0 and 100, calling
"foo(123)" is undefined behaviour.

But once you have taken all these things into account, if your program
attempts to execute something whose behaviour is not defined, then it
/is/ a programming error. And since there is no defined behaviour, and
you haven't asked for anything, there are no restrictions or
requirements on what happens at that point. The compiler can do
anything. The processor can do anything. The libraries can do
anything. The OS can do anything. (Of course some actions might be
more helpful than others in aiding you find the bug.)

There is nothing necessarily wrong with having undefined behaviour in
the code - it is /executing/ undefined behaviour that is wrong. You can
safely have "x = 1 / 0;" in a function that is never called. You can
have "x = a / b;", and execute it - as long as you don't try it with b
equal to 0. You can have code that has undefined behaviour on one
system, and defined behaviour on another. (These are some of the
reasons why it is difficult for tools to warn about undefined behaviour
at compile time.)

So - not all things that are undefined behaviour in the C standard are
programming errors. But executing code whose behaviour is not defined
anywhere in the execution environment, /is/ a programming error.

(And of course there are programming errors that are not undefined
behaviour. The terms are therefore not synonymous.)

>
> ---- If a “shall” or “shall not” requirement that appears outside of
> a constraint or runtime-constraint is violated, the behavior is
> undefined. 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”. ----
>
> Note: "or by the omission of any explicit definition of behavior.".
> What does pthread_create do? There is no explicit definition in the C
> Standard. What does asm do? Same. What does mmap do? Same again. What
> happens when device driver code initiates a DMA operation? Not one
> word in the standard.

These are not defined by the standard, but they will be defined by other
parts of the execution environment.

>
> It is impossible to write a serious C program without producing
> undefined behavior and, certainly, implementations are permitted a
> wide range of action on encountering undefined behavior An
> implementation that chooses, e.g. to implement signed arithmetic by
> delegating semantics to the target processor would be conforming.
>

You misunderstand. You cannot write a useful C program that does not
rely on behaviour that is undefined by the C standard. Equally,
however, you cannot write a correct program that relies on behaviour
that is not defined somewhere in the execution environment. The fact
that the C standard does not define whether the results of "printf" go
to a screen or a file or a debug serial port does not give the
programmer the excuse to let their integers overflow or break the rules
for lvalue accesses!

> The theory that undefined behavior can be treated as impossible has
> very little basis in the C standard text. It is a compiler
> implementation innovation.

The C standard says it imposes /no/ restrictions on how it is treated.
A compiler that considers it as impossible is entirely acceptable based
on the standard - as is a compiler that refuses to compile the code (if
it can prove the code flow passes through the undefined behaviour), or
one that generates binaries which print error messages when the
undefined behaviour occurs, or a toolchain that invokes a debugger when
an attempt to execute undefined behaviour is made. The C standard says
nothing about debuggers or run-time error messages, but those are
equally acceptable.

>
> This is basic. If you are confused about it, your interpretations of
> the C standard are not going to make any sense at all.
>

I agree - but with a rather different view as to what the basic
interpretation of the C standard means!

On Friday, October 15, 2021 at 12:11:58 PM UTC+3, Branimir Maksimovic wrote:
> On 2021-10-14, Thomas Koenig <tko...@netcologne.de> wrote:
> > Branimir Maksimovic <branimir....@icloud.com> schrieb:
> >
> >> Fortran is pre structured era, spagetti code.
> >
> > Your knowledge seems to be stuck in the 1980s.
> >
> > To see what was available in Fortran 95,
> > around 25 years ago, you could try reading
> > https://en.wikipedia.org/wiki/Fortran_95_language_features
> So what do you recommend? Fortran or ADA?
> --

The name of the language is Ada.
ADA is a misspelling preferred by Mitch Alsup. I don't know what are his reasons.

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

BGB <cr88192@gmail.com> writes:

> On 10/12/2021 10:42 AM, Tim Rentsch wrote:
>
>> 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. There are
>> plenty of situations where a C pointer value converted to a
>> different type may be safely and portably dereferenced.
>> Certainly that isn't always true, but it isn't always false
>> either.
>
> Yeah. For some types of code it is desirable to be able to cast
> and dereference a pointer as whatever type matches what one wants
> to do with it. [...]

If what is wanted is to take the bits of one type and interpret
them as bits of a different type (assuming of course that the two
types have the same size), it's easy to do that by using a union
intermediate. (In some cases an intermediate is not needed and
the reinterpretation can be done using conversion of pointer
values.)

If what is wanted is to have pointers of different types that
point to the same memory, and interleave access to the same
memory using the different pointer types, and do that safely,
this cannot be done in general (although it can be done under
some particular sets of conditions).

On 14/10/2021 17:37, Victor Yodaiken wrote:
> On Thursday, October 14, 2021 at 9:24:43 AM UTC-5, David Brown wrote:
>
>> The standard has to provide the lowest common denominator - the most
>> vague version of the language, with the most undefined behaviours and
>> implementation-defined behaviours. It is then up to implementations to
>> tighten these details as appropriate, or offer options for additional
>> semantics.
>>
>
> I disagree. Overuse of UB degrades the semantics of the language and reduces its
> utility.

It is certainly true that undefined behaviour in the standard can reduce
portability, which is one aspect of utility. I see existing UB as
increasing other aspects of utility. But I'd agree that too much UB
would reduce utility.

There are a few cases in the C standards where I think utility could be
improved by changing undefined behaviour into implementation-dependent
behaviour or unspecified behaviour (with explicit options), such as some
cases of bit shift operations. And there are perhaps one or two points
where the compiler should be able to identify the problem at compile
time, and thus a constraint with corresponding required diagnostic would
be better.

> The overhead in dealing with unpredictable unsound optimizations is a serious
> drag on the utility of C.
>

I have used dozens of C compilers over 25 years, primarily for embedded
systems. Baring a small number of compiler bugs, and excluding
pre-release tools or optimisation flags explicitly marked
"experimental", I have not seen any "unsound" optimisations. And I push
my compilers /hard/. I read my compiler manuals, I try out optimisation
flags, and look at the generated assembly.

In my experience, when code (my own or someone else's) "works when
unoptimised, fails when optimised" it is almost invariably a flaw in the
user code - sometimes due to misunderstandings of the C standards, but
mostly due to mistakes in their code.

As to predictability, it is not always easy to predict what improvements
(or regressions) an optimisation will have on the size or speed of
generated code. But the change in functionality should be entirely
predictable - none at all.

>
>> But programmers have to understand that the C language is what is
>> described by the standards, and this is the default for compilers - if
>
> Not necessarily true.

If you mean that compilers are not necessarily standards conforming by
default, then you are correct - and my wording was poor. Most compilers
implement a somewhat expanded or enhanced version of C by default, and
many are lax about acceptance of code structures that are from different
standards versions (such as being basically C90, but accepting some C99
features). However, the C standards are still the initial reference
document for the behaviour of the code unless the compiler documents
something different.

>
>> the C standards don't say what happens when you do X, then neither does
>> the compiler. And if old versions of the standards (including the more
>
> Also not true. For example, GCC says that you can use unions for type puns (which I find
> awkward) although the standard does not.
>

The C standard /does/ say you can use unions for type punning (since C99
- see 6.5.2.3p3 and footnote 97 in C18).

But again, my wording was poor here. When there is no definition of
behaviour for something, compilers can freely do what they want -
including giving you the results you hoped for. And the C compiler may
document guaranteed semantics for something that the C standards leave
undefined, in which case you can rely on it (as long as you are using
that tool).

>> formal descriptions in the K&R books) didn't say what happens when you
>> do X, then it was /never/ part of the language. It doesn't matter if a
>> book used X in an example, or if some compiler happened to generate
>> particular code for X, or if you think it would make more sense if the
>> language defined the behaviour for X, or if some other program uses X in
>> its code.
>
> The Standard is just a document written by a committee. It is not a mathematical theorem
> or law of physics. It is written in ISO bureaucratese, not specified mathematically.
> The standard itself is often vague and contradictory and standards
> experts disagree about fundamental issues - see the memory study group "provenance" paper.

The standard is written and maintained by a committee, which is formed
by and takes input from a range of people involved in the C world. That
includes major users of the language, major compiler developers,
academics, and other interested parties. It is not written by
bureaucrats or some ivory tower group disconnected from reality - it is
written by people for whom the use and success of the language is vital.
And of course they don't always agree - that is the point of having a
committee, considering multiple viewpoints and reaching workable
compromises.

> Even though type alias rules were put in to the standard
> in 1989 (and then repeatedly patched as problems appeared), they represent a significant
> break with K&R C and one the most programmers were perfectly able to ignore for
> decades. They are still only partially and spottily implemented by the compilers.
> When people ask for changes in the standard, they are not asking for
> a flat earth or for 1+1=3.
>

Do you think you are the first to question the effective type rules in
the C standard, or the strict aliasing optimisation in gcc? Do you
think you are the first to wonder if signed integer overflow should be
wrapping on two's complement machines?

People /have/ asked, proposals have written, discussions taken.

During the work for the C++20 standard, there was a proposal to require
two's complement signed integer representation. During that procedure,
there was a suggestion to require wrapping signed arithmetic overflow -
this was solidly rejected, while the restriction on the representation
was solidly approved. C copied the change for the up-coming C23 revision.

No, you are not asking for a flat earth - but you /are/ asking for
things that have been rejected repeatedly, and you are bringing nothing
new to the table.

One plea I have for you and anyone else discussing these things - when
you write these papers and claim that TBAA (or any other optimisation)
provides so little benefit, will you /please/ stop restricting your
efforts to the x86 world? Modern x86 processors are designed to give
fast results from horrible messes of code written for a disaster of an
ISA. Compiler optimisation, or lack thereof, has a lot less of an
effect on the speed of code on these systems. Who cares if the compiler
executes 50 extra instructions when you are already waiting 200
instruction clocks for a memory read to turn up? Who cares about the
speed of the code in a program that has to wait for file I/O ? If you
want to convince people that an optimisation is or is not helpful, then
you also need to show results on ARM servers, GPU cards, embedded
systems, HPC algorithms. Those are systems where a few percent speed
improvements can make a real difference.

>>
>> It is rare that newer versions of the C standards remove semantics from
>> the language - take things that used to work in a particular way, and
>> change them or make them undefined. There have been a few examples -
>> removing implicit int, changing the type of some integer constants,
>> removing the flexibility of implementations to choose rounding modes for
>> division of negative integers. It is, IME, even rarer for C
>> implementations to explicitly guarantee behaviours beyond those required
>> by the C standards.
>
> Consider "asm" which is mentioned once in the standard and has no semantics at
> all attached to it. It is vital to a lot of C code and the compilers guarantee behaviors for
> it. Not the only example, but important.

"asm" is mentioned only as an example of a possible enhancement a C
compiler might have. It is not part of the C standard.

Compilers generally document their own enhancements to the language -
such as an "asm" keyword. What they generally /don't/ document is any
additional semantics that they might implement on features that are part
of the C language but leave some aspects undefined - i.e., the kind of
thing we have been talking about.

I have never seen a compiler manual that documented that accesses via
cast pointers always had the same semantics you'd get via a memcpy()
alternative. (The nearest I have seen is gcc's documentation of the
"-fstrict-aliasing" flag.) I do not recall ever seeing a compiler
manual documenting that signed integer arithmetic had wrapping semantics
(except for gcc's -fwrapv flag).

I have heard many people /claim/ that the compilers they use work this
way. When challenged, some have been able to find example code that
relies on such behaviour - but not documentation guaranteeing it.

David Brown <david.brown@hesbynett.no> writes:

> On 14/10/2021 17:37, Victor Yodaiken wrote:
>> On Thursday, October 14, 2021 at 9:24:43 AM UTC-5, David Brown wrote:
>>

[..]

>
> I'd recommend switching out the pigeonhole principle for something a lot
> more sensible. If you have "n" items to put into "m" containers, and
> each container can only hold one item, then you can't do it and should
> not bother trying. Use fewer items or more containers.

I might be messing something here, but you _can_ do it as long as:
"m >= n" no?

P.S. Enjoyed the rest of the post a lot - tusen takk.

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.

On Friday, October 15, 2021 at 4:32:55 AM UTC-5, David Brown wrote:
> On 14/10/2021 20:20, Victor Yodaiken wrote:
> > "Undefined behavior" does not mean "programming error" and never
> > has. One meaning is just something not specified explicitly in the
> > standard.
> "Undefined behaviour" in the C standard means the C standard does not
> define the behaviour. It really is that simple.
>

Correct. And in this discussion, "undefined behavior" is usually being used to mean
"undefined behavior modulo the ISO C standard". My first point was that it is
fundamentally incorrect to identify undefined behavior in that sense as a
C-Standard programming error. The C Standard only says that the behavior is not defined
by the C Standard and much of what is in C programs qualifies as undefined. The
obvious examples are most system calls, POSIX libraries, interactions with devices,
intrinsics, etc.

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. In fact,
the current interpretation of the standard delegates UB entirely to the compiler.
So compilers are free to leave the semantics of pointer comparison, signed
arithmetic, shifts,etc. to the processor architecture. The decision to pick "UB optimization"
over "processor semantics" on those issues is an engineering decision, not a matter
of compliance with the standard. It is clearly the intention of at least some of the
WG14 that compilers make the decision to "optimize" on UB but it is an intention, not
a requirement. I think the compilers have made a bad decision that makes C less useful
and probably dooms the language to irrelevance (which doesn't necessarily matter for a
compiler that is increasingly focused on other languages). But it is impossible to even discuss the
merits of that decision as long as we get these legalistic claims that there is no alternative.

( On this point, Chris Lattner's discussion of how C-Standard UB has produced what
he called a "terrifying" situation ends with a proposed solution: replace C with Swift)

> The C standard provides /part/ of the description of how a particular
> piece of C source code will act when you run the final binary. The
> documentation (in theory - though we all know how bad software
> documentation can be!) for the C compiler provides additional semantics
> covering everything that the C standard describes as
> "implementation-dependent".

This is confusing, but people need to be clear about it. UB (C-Standard UB) and
implementation dependent (C Standard) are different things.

> But once you have taken all these things into account, if your program
> attempts to execute something whose behaviour is not defined, then it
> /is/ a programming error.

Again, it is important to be clear about terminology. A call to pthread_create
may be UB (C-standard) but perfectly well defined for gcc because gcc
implements POSIX. And what is UB (C-Standard) is defined, by necessity,
by gcc/clang in some way, whether documented or whether it makes sense or not.

> So - not all things that are undefined behaviour in the C standard are
> programming errors. But executing code whose behaviour is not defined
> anywhere in the execution environment, /is/ a programming error.
>

I don't know what that would mean. Everything is defined somewhere, whether as an error
or not is something else.

> You misunderstand. You cannot write a useful C program that does not
> rely on behaviour that is undefined by the C standard.

I this context, I was talking about C-Standard UB, not something wider. Given that, I guess we
agree.

> > The theory that undefined behavior can be treated as impossible has
> > very little basis in the C standard text. It is a compiler
> > implementation innovation.
> The C standard says it imposes /no/ restrictions on how it is treated.
> A compiler that considers it as impossible is entirely acceptable based
> on the standard

I doubt this, but I am confident that debating the meaning of the standard on this
point is not a useful exercise.

On 14/10/2021 20:44, BGB wrote:
> On 10/14/2021 11:49 AM, Thomas Koenig wrote:
>> Victor Yodaiken <victor.yodaiken@gmail.com> schrieb:
>>> On Thursday, October 14, 2021 at 9:24:43 AM UTC-5, David Brown wrote:
>>>
>>>> The standard has to provide the lowest common denominator - the most
>>>> vague version of the language, with the most undefined behaviours and
>>>> implementation-defined behaviours. It is then up to implementations to
>>>> tighten these details as appropriate, or offer options for additional
>>>> semantics.
>>>>
>>>
>>> I disagree. Overuse of UB degrades the semantics of the language
>>> and reduces its utility.  The overhead in dealing with unpredictable
>>> unsound optimizations is a serious drag on the utility of C.
>>
>> Let's called "undefined behavior" what it is - programming errors,
>> and see how much your sentence makes sense then.
>>
>
> This would only be true IMO, if all of the "undefined behavior" cases
> only represented things which could happen unintentionally, or which
> otherwise did not serve any use.
>

That does not make sense. Why would you intentionally make a
programming error?

What you describe below is not "intentionally using undefined behaviour"
- it is wishful thinking where the programmer believes the code has some
semantics when it does not. (Well, it /might/ have those semantics on
some compiler with particular options, if the compiler documents them -
in which case it is valid but non-portable code.)

> Many of the common cases are things which have "perfectly reasonable"
> behavior on most targets, and are themselves useful for writing
> straightforward and performant code, but none the less fall outside the
> scope of the C standard.

Regardless of what any one given programmer thinks is "perfectly
reasonable", if you write code that executes undefined behaviour, it is
a programmer error. A programming language is not defined by what /you/
want it to mean, nor is compiler behaviour defined by what /you/ think
is "reasonable". (Well, it might be in your particular case, when you
write your own compiler!)

>
>
> Eg:
>   Signed right shift;
>   Signed integer overflow;
>   Ability to cast and dereference pointers as
>     "whatever the hell one wants";
>   ...
>

I think coffee should be available for free, Brussel sprouts should be
illegal, and that there should be three Tuesdays in every week. To me,
these are perfectly reasonable requests, but that does not make them true.

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.

On 15/10/2021 15:42, Victor Yodaiken wrote:
> 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.
>

True - but it is a clarification of the normative text in 6.5.2.3p3:

"""
A postfix expression followed by the . operator and an identifier
designates a member of a structure or union object. The value is that of
the named member, 97) and is an lvalue if the first expression is an
lvalue. If the first expression has qualified type, the result has the
so-qualified version of the type of the designated member.
"""

(The footnote is number 97 in N2176, rather than 95, but the normative
paragraph is the same.)

The intention of the C standard was always to allow type-punning via
unions, but many people found the text unclear. So the footnote was
added (in C99, IIRC) to make the implications of the text clearer while
also making it obvious that the specified behaviour had not changed.

On 15/10/2021 14:50, clamky@hotmail.com wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 14/10/2021 17:37, Victor Yodaiken wrote:
>>> On Thursday, October 14, 2021 at 9:24:43 AM UTC-5, David Brown wrote:
>>>
>
> [..]
>
>>
>> I'd recommend switching out the pigeonhole principle for something a lot
>> more sensible. If you have "n" items to put into "m" containers, and
>> each container can only hold one item, then you can't do it and should
>> not bother trying. Use fewer items or more containers.
>
> I might be messing something here, but you _can_ do it as long as:
> "m >= n" no?
>

Yes - the pigeonhole principle is about n > m. But it might have made
more sense if I had written that!

> P.S. Enjoyed the rest of the post a lot - tusen takk.
>

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.

On 14/10/2021 21:34, Stefan Monnier wrote:
> David Brown [2021-10-14 16:24:40] wrote:
>> The standard has to provide the lowest common denominator - the most
>> vague version of the language, with the most undefined behaviours and
>> implementation-defined behaviours. It is then up to implementations to
>> tighten these details as appropriate, or offer options for additional
>> semantics.
>>
>> But programmers have to understand that the C language is what is
>> described by the standards, and this is the default for compilers - if
>> the C standards don't say what happens when you do X, then neither does
>> the compiler.
>
> There lies the problem: the standard is bound by the "lowest common
> denominator" and then compilers in turn use this lower target, rather
> than having an intermediate target which is made more precise by relying
> on extra knowledge of the target system.
>
> This has the side effect that if you take code which relies on having
> a flat address space, it can't be used reliably even if you make sure
> it's only used on systems with a flat address space.
>

High level languages - and C is a high level language - are defined in
terms of abstract machines, not the hardware. C's abstract machine is
intended to be an efficient match to real systems, and some certain
aspects of it (such as the size of "int") are "configurable" to match
hardware. But most of it is not (nor has it ever been) an attempt to
model exact hardware. Flat address spaces is not a concept that is part
of the C abstract machine. If you want a language that has "flat
address space" as part of its definition, C is not that language.

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

All languages pick a level of abstraction somewhere between precise
processor models at one end, and human thought (or perhaps mathematical
specification languages) at the other end. C has picked its level - and
that level does not suit everyone or every usage (understandably
enough). Problems arise when people use C without understanding where
it lies in this abstraction spectrum. People get worked up when they
understand where C lies but are convinced it should be elsewhere.

The /real/ trouble is the people who /know/ it lies at one spot, believe
it should be elsewhere, and then write code as though it were elsewhere
(typically at a lower level than it really is). And those are often the
people that complain loudest when their programming errors manifest
themselves as user-visible bugs.

> [ I mean, yes, in practice, it can be used, but you can never be sure
> it'll work: instead, you have to try it out, see where it breaks,
> figure out which trick to use to prevent the undesired "optimization",
> ... until you decide that it experimentally seems to work well enough
> for the current version of your compiler. ]
>
> Maybe for `<` and `-` between pointers to unrelated objects, the
> standard should say that this is not UB when used on a system with
> a flat address space (and that while the exact return value is
> implementation dependent, it obeys the usual rules of those operators).
>

That would be entirely reasonable. It could also say that if the
implementation supports uintptr_t, then comparison of any two object
pointers should be interpreted as a comparison between the results of
casting the pointers to uintptr_t.

But it doesn't say that.

Any compiler implementation could provide this as extra semantics, very
easily. And it could document this behaviour, so that people using that
compiler could rely on that feature.

But they don't say that (at least, not in any compiler manual I have
read or heard of).

Perhaps such features aren't really that useful after all?

(Note that any use in the implementation of C standard library functions
can rely on undocumented compiler features.)

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)

On 10/15/2021 6:49 AM, Tim Rentsch wrote:
> BGB <cr88192@gmail.com> writes:
>
>> On 10/12/2021 10:42 AM, Tim Rentsch wrote:
>>
>>> 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. There are
>>> plenty of situations where a C pointer value converted to a
>>> different type may be safely and portably dereferenced.
>>> Certainly that isn't always true, but it isn't always false
>>> either.
>>
>> Yeah. For some types of code it is desirable to be able to cast
>> and dereference a pointer as whatever type matches what one wants
>> to do with it. [...]
>
> If what is wanted is to take the bits of one type and interpret
> them as bits of a different type (assuming of course that the two
> types have the same size), it's easy to do that by using a union
> intermediate. (In some cases an intermediate is not needed and
> the reinterpretation can be done using conversion of pointer
> values.)
>

Yeah, a union works, but it is kinda awkward.

> If what is wanted is to have pointers of different types that
> point to the same memory, and interleave access to the same
> memory using the different pointer types, and do that safely,
> this cannot be done in general (although it can be done under
> some particular sets of conditions).
>

Granted, this is one weakness of most of my "TBAA but with local
exclusion" ideas.

Arguably, one would want something like "volatile, but weaker".
If one were to abuse volatile for this, then it would create incentive
to try to "optimize" the use of volatile, defeating its primary reason
for existing (namely things like memory-mapped IO and similar).

But, say, we can have an optional 'may_alias' keyword (or something to
this effect), say, which could be defined as, say:
#ifdef __CC_HAS_ALIAS__
#define may_alias [[may_alias]] //nicer attribute syntax
#elif defined(_MSC_VER)
#define may_alias // MSVC doesn't use TBAA by default
#elif defined(__GNUC__)
#define may_alias __attribute__((may_alias)) // GCC already has this
#else
#define may_alias volatile // well, whatever, use 'volatile'
#endif

then, say:
void foo(may_alias int *pa, may_alias float *pb)
{ ...
}

Where the compiler may not make any TBAA style assumptions about whether
'pa' or 'pb' may alias with each other, but which may still cache values
in other contexts (which do not depend on aliasing between these
pointers), unlike volatile which sort of forces every access though
these pointers to do a load or store (making it sort of a sledgehammer
solution to the usual TBAA issues).

Likewise, it would not require disabling TBAA for the entire program.

This could be used in combination with local exclusion, just with the
drawback that local exclusion is local.

On 10/15/2021 10:38 AM, 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.
>
> There is nothing in the C standard that privileges one interpretation of C UB over
> another one.
>

Agreed.

In my compiler, I have made 'fwrapv' style semantics the default as well.

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.

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. In fact, C is unusual
in that the definition of the language both by its authors and even by the
committee memo called the Standard, specifically and clearly defines
the C specification to be *incomplete*. The language delegates a great
deal of its semantics to something else. The argument we are having here
is that some are satisfied to delegate more to the compiler and are happy
with an emphasis on semantically shaky optimizations, and some want
to either define more precisely or to delegate more to the
programmer and hardware.

The difficulty with this debate is that a number
of people who support the design approach of delegation to the compiler
and UB based optimization are not willing to defend that approach on
technical grounds, but seek
to end discussion by falsely claiming the issues have all been settled
and that any disagreement is based on the stupidity or ignorance
of the critics. Fine, if you are happy with the mess that ISO-C
has made of C Semantics, say so, or ignore the discussion. But your
design preferences are not laws of physics or even laws of society, they
are no more than design preferences. They are not even unchangeable
aspects of the Standard. Even if the ISO-C Standard
unambiguously supported your design preferences, which it
definitely does not, it's just a committee memo and, from my
time on the WG14 committee, I know that a number of members of
the committee are not in favor of the status quo.

>C's abstract machine is
> intended to be an efficient match to real systems, and some certain
> aspects of it (such as the size of "int") are "configurable" to match
> hardware. But most of it is not (nor has it ever been) an attempt to
> model exact hardware. Flat address spaces is not a concept that is part
> of the C abstract machine. If you want a language that has "flat
> address space" as part of its definition, C is not that language.

The Bell Labs papers on C, both editions of K&R, and the Plan 9 C
compilers/papers don't mention or rely on either the concepts of "abstract
machine" or undefined-behavior. So your statement has a chance of
being true if you replace "C" with "ISO-C as currently interpreted".
The ISO-C standard does not define C, it defines a supposedly
common dialect. And, as mentioned above, ISO-C specifically
defines its abstract machine to be incomplete.

As for "flat address space", it's a remarkable choice of a hill to die on.
Over the last 40 years, processor architectures have converged on
a simple uniform "flat" address space (as they have on modular
arithmetic). It is a highly useful abstraction
and improves processor performance. ARM, x86, Mips, RISC-V, Power -
etc. all have these "flat address" spaces.

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

This is an interesting complaint, because from the point of view of someone
who has written a lot of time constrained code, the complex and poorly
defined semantics of ISO-C is a serious impediment. And, of course, I am
not the only person to make that point. It's a startling feature of this
debate that people feel qualified to dismiss, for example, DJB's critique of ISO-C
as if he was some apprentice who picked up the wrong end of a saw.

>
> All languages pick a level of abstraction somewhere between precise
> processor models at one end, and human thought (or perhaps mathematical
> specification languages) at the other end. C has picked its level - and
> that level does not suit everyone or every usage (understandably
> enough). Problems arise when people use C without understanding where
> it lies in this abstraction spectrum. People get worked up when they
> understand where C lies but are convinced it should be elsewhere.

Again: you confuse your idea of what C semantics should be with some
fundamental standard that other people have failed to understand.

>
> Perhaps such features aren't really that useful after all?
>

As I am sure you know, technology development is not entirely determined by
merit. The terrible Itanic architecture via the power of its corporate backing
had a big influence on ISO-C (all those "trap" representations, for example).
Similarly, the FAANG piper plays the tune for gcc/clang these days.

You cannot prove technical flaws in a proposal by pointing out that some
middle managers at Google don't like it.

MitchAlsup <MitchAlsup@aol.com> writes:

> 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

I don't think comp.lanG.c is a place to discuss this. comp.std.c might
be a better choice, but it's not nearly as vibrant as comp.arch.

People here might, and do!, provide insights ofter overlooked by
regulars in more software oriented NGs.

Much of what is being discussed in this thread is intertwined with
hardware, some decisions that lead to certain things being UB were, I
believe, made that way by the committee because there existed weird
architectures that needed to have a working/able C implementation.

Take C's 'char' type for instance - the standard defines it as being
distinct from both unsigned and signed chars, why? I have no clue (just
guesses) (POC being unsigned on PPC made for a some interesting
surprises)

What possessed creators of AIX to make address zero readable and thus
completely breaking the expectations of Mono? (Some insights into this
were, if my memory serves, provided on LKML and it might have been more
widespread in the past not limeted to AIX/PPC)

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

While the discussion certainly swayed more towards C in general it seems
to me that is still topical here.

On Friday, October 15, 2021 at 12:54:20 PM UTC-5, cla...@hotmail.com wrote:
> MitchAlsup <Mitch...@aol.com> writes:
>
> > 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
<
> I don't think comp.lanG.c is a place to discuss this. comp.std.c might
> be a better choice, but it's not nearly as vibrant as comp.arch.
>
> People here might, and do!, provide insights ofter overlooked by
> regulars in more software oriented NGs.
>
> Much of what is being discussed in this thread is intertwined with
> hardware, some decisions that lead to certain things being UB were, I
> believe, made that way by the committee because there existed weird
> architectures that needed to have a working/able C implementation.
<
You two have discussed this and that up and down without touching HW
in the last week; except to point out that all HW is not the same with respect
to; exceptions, shifts, overflow, variable shift direction,... That is NOT about
but about how some ancient piece of HW that still exists BLEW IT. IT is
fine to dwell on this for a short moment and reiterate that they BLEW IT
so to edumacate others in "Don't Do That". But you can't change C towards
what a well designed architecture will do without any provocation because
there are so many poor architectures out there that still exist (x86 being
one of them; with ARM not that far behind).
>
> Take C's 'char' type for instance - the standard defines it as being
> distinct from both unsigned and signed chars, why? I have no clue (just
> guesses) (POC being unsigned on PPC made for a some interesting
> surprises)
<
It is distinct because "char" is supposed to be an efficient container of
characters (of whatever encoding). S/360 has unsigned bytes, as do
several (now defunct) minicomputers, while others had signed bytes.
It seems to me that the proper course of any modern architecture is
to provide BOTH signed and unsigned bytes; and let the compiler
choose which one to use.
<
Another rational is that characters are not manipulated in ways where
being signed or unsigned is of an advantage. They are range checked
'a'..'z' ,... '0'..'9',..., but quite often they are universally compared using
table[c] & StartsAlphanumeric,...
>
> What possessed creators of AIX to make address zero readable and thus
> completely breaking the expectations of Mono? (Some insights into this
> were, if my memory serves, provided on LKML and it might have been more
> widespread in the past not limeted to AIX/PPC)
<
Does AIX exist is enough implementations that its existence is relevant to a
long discussion of 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.
<
> While the discussion certainly swayed more towards C in general it seems
> to me that is still topical here.
<
You two have spend nearly a week talking about stuff that properly done
HW does not need discussed. Properly done HW fully supports C and
enables efficient compilation--including all the type punning, parameter
passing punning, pointer punning, pointer aliasing,.....And while fully supporting
C there is nothing that prevents such HW from supporting FORTRAN, Ada,
Cobol, RPG, LISP, Snobol, Jovial, Smalltalk, Sisal, and many more.
<
But I guess I am biased in that when writing OS-like codes, the source code
should be written as if optimization was set to -O-99 (do absolutely no
optimization.) In these codes it is more important to never get in a position
where optimization crashes a system, than it is to achieve 180ps faster run
times.
<
So, you say (SAY) the discussion was pertinent to HW, I ask what nuance of
a typical function unit that could be modified such that your discussion would
have taken 10% the thread length it has currently taken--showing no sign of
abatement.
<
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?
<
What could be changed in the EXECUTE unit to make those C un-specifications
better?
<
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?
<
What could be changed in the FP-UNIT unit to make those C un-specifications
better?
<
What could be changed in either CACHE unit to make those C un-specifications
better?
<
What could be changed in the MMU unit to make those C un-specifications
better?
<
What could be changed in the L2 Cache unit to make those C un-specifications
better?
<
What could be changed in the Register File Organization to make those C un-specifications
better?
<
What could be changed in the Call-Return specification to make those C un-specifications
better?
<
What could be changed in the switch specification to make those C un-specifications
better?
<
What could be changed in the DRAM unit to make those C un-specifications
better?
<
What could be changed in the Exception specification to make those C un-specifications
better?
<
What could be changed in the ProgramStatusContainer to make those C un-specifications
better?
<
What could be changed in the MEMORY-Model to make those C un-specifications
better?
<
What could be changed in the Branch-Predictor to make those C un-specifications
better?
<
What could be changed in the Context-Switch to make those C un-specifications
better?
<
What could be changed in the PCIe-device-I/O to make those C un-specifications
better?
<
What could be changed in the Interrupt specification to make those C un-specifications
better?
<
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 ?
<
Where is the HW relevance ?? I don't see it !!--unless you can point at one of the 20
units mentioned above and make a concrete suggestion as to how does one make
one of those better, that makes the problems of C vanish !
<
Where is the architecture relevance ?? I don't see it either.
<

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.

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

BGB <cr88192@gmail.com> schrieb:
> On 10/15/2021 1:26 AM, Thomas Koenig wrote:

>> C has perfectly good unsigned integers. Instead of (assuming 32-bit
>> ints here)
>>
>> int i;
>> ...
>> i = i >> 1;
>>
>> what's wrong with
>>
>> i = ((unsigned int) i) >> 1;
>>
>> or
>>
>> i = (((unsigned int) i) >> 1) | (((unsigned int) i) & (1u << 31));
>>
>> thus telling the compiler exactly what it should do with the sign
>> bit, and being portable at the same time? If you don't like to
>> write it out, put it in a macro or a static inline function in a
>> header somewhere (better type-safety that way), and you're done.
>>
>
> This requires heavy lifting from the compiler to realize that this
> convoluted mess represents an arithmetic shift.

So what. That's what compilers do these days - heavy lifting.
If gcc does not handle that in an architecture which supports
arithmetic right shifts directly on an architecture, submit a PR.

There is a very interesting file in the gcc sources - match.pd,
you can browse it at
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/match.pd;h=038a7981c0e4b818d17506bcafd35401794dce42;hb=refs/heads/trunk

It contains code like, for example,

/* Transform { 0 or 1 } * { 0 or 1 } into { 0 or 1 } & { 0 or 1 } */
(simplify
(mult SSA_NAME@1 SSA_NAME@2)
(if (INTEGRAL_TYPE_P (type)
&& get_nonzero_bits (@1) == 1
&& get_nonzero_bits (@2) == 1)
(bit_and @1 @2)))

so there is

> It is easier, for both normal programmers and the compiler implementers,
> to declare that signed right shift is an arithmetic shift.

This is a matter of correctness of the program. A program with a
signed right shift is erroneous, the example above isn't.

> It is like asking people to use byte operations and shifts to read
> values. Some compilers can figure it out (and turn it into a plain
> load), while some others will give byte operations and shifts.

Who is asking that?

>>> Ability to cast and dereference pointers as
>>> "whatever the hell one wants";
>>
>> "cast" using memcpy to make your intentions clear to the compiler.
>>
>
> It depends on the compiler being clever to make it "not suck" (eg: turn
> the memcpy call into a register operation or similar).

This is 2021. We are talking about optimizing compilers. If this
does indeed suck, submit a PR (but it very probably will not).

> So, if the compiler is clever, it works.
> But, if the compiler is not as clever and tries to do a memory copy
> operation (or, worse, actually calls memcpy), then it sucks...
>
> It is also a lot more awkward to type than (ab)using the use of pointer
> casts and dereferencing.

Convenience over correctnes, right.

> The main tradeoff is that one can't use strict aliasing semantics, but
> then it is notable that a number of projects explicitly disable
> strict-aliasing on compilers which use it.

For legacy code, I can sort of understand it.

I would, however, dearly love a sanitizer which catches this problem.

On Friday, October 15, 2021 at 2:27:20 PM UTC-5, MitchAlsup wrote:

> You two have discussed this and that up and down without touching HW

1. Why do I have to pay the price of snooping cache everywhere when programs don't
usually share much memory?
2. with the increasing numbers of registers, shouldn't we have a dirty bit so
a process can save register state more efficiently with a "save-dirty-registers"
instruction and a "fetch bitmap; load-saved-registers" instruction? Or otherwise reduce
the expense of context switch?
3. Why is device IO so effin complex if devices are getting smarter.
4. why is virtualization such a kludge and why can't a supervisory core safely
and efficiently sandbox other cores?
5. Pipelined systems should be able to peg memory bandwidth with a simple loop

x: load (R1) to R2
store R2,(R3)
add 8,R1
add 8, R3
cmp R1, R5
ble x

But they can't. Instead compilers screw around with vector registers clumsily
6. why is it so hard to delegate simple computations to gpus? Why can't the main OS
simply dynamically compile and load simple loops for the GPUs ?
7. Can't we get rid of interrupts?

> in the last week; except to point out that all HW is not the same with respect
> to; exceptions, shifts, overflow, variable shift direction,... That is NOT about
> but about how some ancient piece of HW that still exists BLEW IT. IT is
> fine to dwell on this for a short moment and reiterate that they BLEW IT
> so to edumacate others in "Don't Do That". But you can't change C towards
> what a well designed architecture will do without any provocation because
> there are so many poor architectures out there that still exist (x86 being
> one of them; with ARM not that far behind).
> >
> > Take C's 'char' type for instance - the standard defines it as being
> > distinct from both unsigned and signed chars, why? I have no clue (just
> > guesses) (POC being unsigned on PPC made for a some interesting
> > surprises)
> <
> It is distinct because "char" is supposed to be an efficient container of
> characters (of whatever encoding). S/360 has unsigned bytes, as do
> several (now defunct) minicomputers, while others had signed bytes.
> It seems to me that the proper course of any modern architecture is
> to provide BOTH signed and unsigned bytes; and let the compiler
> choose which one to use.
> <
> Another rational is that characters are not manipulated in ways where
> being signed or unsigned is of an advantage. They are range checked
> 'a'..'z' ,... '0'..'9',..., but quite often they are universally compared using
> table[c] & StartsAlphanumeric,...
> >
> > What possessed creators of AIX to make address zero readable and thus
> > completely breaking the expectations of Mono? (Some insights into this
> > were, if my memory serves, provided on LKML and it might have been more
> > widespread in the past not limeted to AIX/PPC)
> <
> Does AIX exist is enough implementations that its existence is relevant to a
> long discussion of 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.
> <
> > While the discussion certainly swayed more towards C in general it seems
> > to me that is still topical here.
> <
> You two have spend nearly a week talking about stuff that properly done
> HW does not need discussed. Properly done HW fully supports C and
> enables efficient compilation--including all the type punning, parameter
> passing punning, pointer punning, pointer aliasing,.....And while fully supporting
> C there is nothing that prevents such HW from supporting FORTRAN, Ada,
> Cobol, RPG, LISP, Snobol, Jovial, Smalltalk, Sisal, and many more.
> <
> But I guess I am biased in that when writing OS-like codes, the source code
> should be written as if optimization was set to -O-99 (do absolutely no
> optimization.) In these codes it is more important to never get in a position
> where optimization crashes a system, than it is to achieve 180ps faster run
> times.
> <
> So, you say (SAY) the discussion was pertinent to HW, I ask what nuance of
> a typical function unit that could be modified such that your discussion would
> have taken 10% the thread length it has currently taken--showing no sign of
> abatement.
> <
> 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?
> <
> What could be changed in the EXECUTE unit to make those C un-specifications
> better?
> <
> 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?
> <
> What could be changed in the FP-UNIT unit to make those C un-specifications
> better?
> <
> What could be changed in either CACHE unit to make those C un-specifications
> better?
> <
> What could be changed in the MMU unit to make those C un-specifications
> better?
> <
> What could be changed in the L2 Cache unit to make those C un-specifications
> better?
> <
> What could be changed in the Register File Organization to make those C un-specifications
> better?
> <
> What could be changed in the Call-Return specification to make those C un-specifications
> better?
> <
> What could be changed in the switch specification to make those C un-specifications
> better?
> <
> What could be changed in the DRAM unit to make those C un-specifications
> better?
> <
> What could be changed in the Exception specification to make those C un-specifications
> better?
> <
> What could be changed in the ProgramStatusContainer to make those C un-specifications
> better?
> <
> What could be changed in the MEMORY-Model to make those C un-specifications
> better?
> <
> What could be changed in the Branch-Predictor to make those C un-specifications
> better?
> <
> What could be changed in the Context-Switch to make those C un-specifications
> better?
> <
> What could be changed in the PCIe-device-I/O to make those C un-specifications
> better?
> <
> What could be changed in the Interrupt specification to make those C un-specifications
> better?
> <
> 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 ?
> <
> Where is the HW relevance ?? I don't see it !!--unless you can point at one of the 20
> units mentioned above and make a concrete suggestion as to how does one make
> one of those better, that makes the problems of C vanish !
> <
> Where is the architecture relevance ?? I don't see it either.
> <