Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Sat, 14 Sep 2024 00:04:07 -0500
Organization: A noiseless patient Spider
Lines: 107
Message-ID: <vc35gk$1a8l8$1@dont-email.me>
References: <vaqgtl$3526$1@dont-email.me>
 <memo.20240830090549.19028u@jgd.cix.co.uk>
 <2024Aug30.161204@mips.complang.tuwien.ac.at> <86r09ulqyp.fsf@linuxsc.com>
 <2024Sep8.173639@mips.complang.tuwien.ac.at>
 <p1cvdjpqjg65e6e3rtt4ua6hgm79cdfm2n@4ax.com>
 <2024Sep10.101932@mips.complang.tuwien.ac.at> <ygn8qvztf16.fsf@y.z>
 <2024Sep11.123824@mips.complang.tuwien.ac.at> <vbsoro$3ol1a$1@dont-email.me>
 <867cbhgozo.fsf@linuxsc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 14 Sep 2024 07:04:20 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="cc93f9ab63efe860553c151b195d90ed";
	logging-data="1385128"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18P7oj5BsOcJj/73KUI/fBaRKNHyrIaKXs="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:hRptWQVZ1uf3bUZQzC8yWTezVJA=
Content-Language: en-US
In-Reply-To: <867cbhgozo.fsf@linuxsc.com>
Bytes: 5126

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.

....