Re: Computer architects leaving Intel...

On 9/12/2024 5:12 AM, Tim Rentsch 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.

There are a few ways things can go:
   Define rules, have one of N permutations for how those rules can go;
     How it often worked in practice.
   Throw up hands and say it is unknowable.
     What a lot of "portability" people assert.
   Do whatever gives the fastest results in standardized benchmarks.
     What many compiler maintainers want.
And, the tradeoff:
Compilers are often not as clever as some people assert;
For some types of code, or on some targets, things like performance and memory usage are significant concerns (often more so than whether or not the code is particularly portable).
Often, a bigger concern may be whether the code does what is expected on the type of machine it is being used on, and how effectively it does so, rather than how it may behave (or work at all) on some other type of machine (outside of the given application scope).
But, in these cases, it would be more useful to know what claims can be made about the behavior on a specific machine, rather than what is the scope of possible behaviors.
But, one may care more strongly in this case about things like endianess and whether or not it is safe on a given target to use misaligned memory accesses, etc. And, in these cases, one doesn't really want compilers to do anything which may lead to inconsistencies in terms of observable behavior; but rather one would rather have some way to know what policies the compiler intends to act on in terms of behaviors.
This is why I was mentioning things like having some way to know whether the compile uses strict aliasing. It may make sense in these cases to have generic fallbacks, say, for compilers that have strict aliasing and don't allow misaligned pointers, vs other compilers that are using conservative aliasing rules and allow misaligned access, ...
Say, for example, one could do a bit-stream reader function (Version A):
int ReadBits(BitsContext *ctx, int nbits)
{
  int b;
   b=ctx->win>>ctx->pos;
   ctx->pos+=nbits;
   b&=(1<<nbits)-1;
   while(ctx->pos>=8)
   {
     ctx->win=(ctx->win>>8)|((*ctx->cs++)<<24);
     ctx->pos-=8;
   }
   return(b);
}
And another version (Version B):
int ReadBits(BitsContext *ctx, int nbits)
{
   byte *cs;
   u32 w;
   int p, b, m;
   cs=ctx->cs;
   p=ctx->pos;
   w=*(u32 *)cs;
   m=(1<<nbits)-1;
   b=w>>p;
   p+=nbits;
   b&=m;
   ctx->cs=cs+(p>>3);
   ctx->pos=p&7;
   return(b);
}
Now, say, there is one machine where version B is significantly faster than A, and another machine where B is not usable at all. And, maybe a 3rd machine exists where the operation can be done in a few special-purpose ASM instructions via inline assembler.
It is useful to be able to know which is which.
Then, if you don't know which is which, the program can fall back to a default/safe option.
...