Re: Computer architects leaving Intel...

Michael S <already5chosen@yahoo.com> writes:

On Fri, 13 Sep 2024 04:12:21 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>

Michael S <already5chosen@yahoo.com> writes:
>

On Thu, 12 Sep 2024 03:12:11 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>

BGB <cr88192@gmail.com> writes:
>
[...]
>

Would be nice, say, if there were semi-standard compiler macros
for various things:
  Endianess (macros exist, typically compiler specific);
    And, apparently GCC and Clang can't agree on which strategy to
use.  Whether or not the target/compiler allows misaligned memory
access;  If set, one may use misaligned access.
  Whether or not memory uses a single address space;
    If set, all pointer comparisons are allowed.
>
[elaborations on the above]

>
I suppose it's natural for hardware-type folks to want features
like this to be part of standard C.  In a sense what is being
asked is to make C a high-level assembly language.  But that's
not what C is.  Nor should it be.

>
Why not?

>
Because it's not needed, and would make things worse rather
than better.  The result would be a bigger language but not
a better language.

>
I beg to differ.
Yes, the standard would be bigger.  And yes, few unimportant benchmarks
would run a little slower.  But a job of compiler writers would be
simpler and less exciting (good thing!).  The most importantly,
programming in resulting language would feel more predictable.
>

I don't see practical need for all those UBs apart from buffer
overflow.  More so, I don't see the need for UB in certain
limited classes of buffer overflows.

>
Eliminating undefined behavior is not what's being asked for.
These two questions are not the same.
>

struct {
 char x[8]
 int  y;
} bar;
bar.y = 0; bar.x[8] = 42;
>
IMHO, here behavior should be fully defined by implementation.  And
in practice it is.  Just not in theory.

>
Do you mean union rather than struct?  And do you mean bar.x[7]
rather than bar.x[8]?  Surely no one would expect that storing
into bar.x[8] should be well-defined behavior.
>
If the code were this
>
    union {
      char x[8];
      int  y;
    } bar;
    bar.y = 0;  bar.x[7] = 42;
>
and assuming sizeof(int) == 4, what is it that you think should
be defined by the C standard but is not?  And the same question
for a struct if that is what you meant.

>
No, I mean struct and I mean 8.
And I mean that a typical implementation-defined behavior would be
bar.y==42 on LE machines and bar.y==42*2**24 on BE machines.
As it actually happens in reality with all production compilers.

I think the consequences of changes like the ones you suggest
would be much larger than you think they would be.  The result
would change C into a completely different language.

Also I think the percentage of code where such considerations are
relevant is extremely small, significantly less than a thousandth
of a percent.  That's a mighty small tail wagging a mighty large
dog.

I'm not trying to convince anyone;  just stating a personal view.