Path: ...!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Fri, 13 Sep 2024 17:30:35 +0200
Organization: A noiseless patient Spider
Lines: 221
Message-ID: <vc1lqs$u8cm$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>
 <vbut86$9toi$1@dont-email.me> <vbvljl$ea0m$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 13 Sep 2024 17:30:37 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="62baffe00b005c9dd99479aa197dcc2f";
	logging-data="991638"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX191kj1BTVTMibCpZicQXK3CPg1T4zkXA84="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:54KcaL4e8p6JedZMf1Vs3kP+rw8=
In-Reply-To: <vbvljl$ea0m$1@dont-email.me>
Content-Language: en-GB
Bytes: 9647

On 12/09/2024 23:14, BGB wrote:
> On 9/12/2024 9:18 AM, David Brown wrote:
>> On 11/09/2024 20:51, BGB wrote:
>>> On 9/11/2024 5:38 AM, Anton Ertl wrote:
>>>> Josh Vanderhoof <x@y.z> writes:
>>>>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>>>

<snip lots>

>>> Would be nice, say, if there were semi-standard compiler macros for 
>>> various things:
>>
>> Ask, and you shall receive!  (Well, sometimes you might receive.)
>>
>>>    Endianess (macros exist, typically compiler specific);
>>>      And, apparently GCC and Clang can't agree on which strategy to use.
>>
>> #if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
>> ...
>> #elif __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
>> ...
>> #else
>> ...
>> #endif
>>
>> Works in gcc, clang and MSVC.
>>
> 
> Technically now also in BGBCC, since I have just recently added it.

Good idea.

> 
>>
>> And C23 has the <stdbit.h> header with many convenient little "bit and 
>> byte" utilities, including endian detection:
>>
>> #include <stdbit.h>
>> #if __STDC_ENDIAN_NATIVE__ == __STDC_ENDIAN_LITTLE__
>> ...
>> #elif __STDC_ENDIAN_NATIVE__ == __STDC_ENDIAN_BIG__
>> ...
>> #else
>> ...
>> #endif
>>
> 
> This is good at least.
> 
> Though, generally takes a few years before new features become usable.
> Like, it is only in recent years that it has become "safe" to use most 
> parts of C99.
> 

Most of the commonly used parts of C99 have been "safe" to use for 20 
years.  There were a few bits that MSVC did not implement until 
relatively recently, but I think even have caught up now.

There are only two serious, general purpose C compilers in mainstream 
use - gcc and clang, and both support almost all of C23 now.  But it 
will take a while for the more niche tools, such as some embedded 
compilers, to catch up.

<stdbit.h> is, however, in the standard library rather than the 
compiler, and they can be a bit slow to catch up.

>>
>>>    Whether or not the target/compiler allows misaligned memory access;
>>>      If set, one may use misaligned access.
>>
>> Why would you need that?  Any decent compiler will know what is 
>> allowed for the target (perhaps partly on the basis of compiler 
>> flags), and will generate the best allowed code for accesses like 
>> foo3() above.
>>
> 
> Imagine you have compilers that are smart enough to turn "memcpy()" into 
> a load and store, but not smart enough to optimize away the memory 
> accesses, or fully optimize away the wrapper functions...
> 

Why would I do that?  If I want to have efficient object code, I use a 
good compiler.  Under what realistic circumstances would you need to 
have highly efficient results but be unable to use a good optimising 
compiler?  Compilers have been inlining code for 30 years at least 
(that's when I first saw it) - this is not something new and rare.

> So, for best results, the best case option is to use a pointer cast and 
> dereference.
> 
> For some cases, one may also need to know whether or not they can access 
> the pointers in a misaligned way (and whether doing so would be better 
> or worse than something like "memcpy()").
> 

Again, I cannot see a /real/ situation where that would be relevant.

> 
>>>    Whether or not memory uses a single address space;
>>>      If set, all pointer comparisons are allowed.
>>
>> Pointer comparisons are always allowed for equality tests if they are 
>> pointers to objects of compatible types.  (Function pointers cannot be 
>> compared at all.)
>>
>> For other relational tests, the pointers must point to sub-objects of 
>> the same aggregate object.  (That means they can't be null pointers, 
>> misaligned pointers, invalid pointers or pointers going nowhere.)  
>> This is independent of how the address space(s) are organised on the 
>> target machine.
>>
>> What you /can/ do, on pretty much any implementation with a single 
>> linear address space, is convert pointers to uintptr_t and then 
>> compare them.  There may be some targets for which there is no 
>> uintptr_t, or where the mapping from pointer to integer does not match 
>> with the address, but that would be very unusual.
>>
>> I can't think when you would need to do such comparisons, however, 
>> other than to implement memmove - and library functions can use any 
>> kind of implementation-specific feature they like.
>>
> 
> Yeah.
> 
> My "_memlzcpy()" functions do a lot of relative comparisons (more than 
> needed for memmove):
>    dst<=src: memmove
>    (dst-src)>=sz: memcpy
>    (dst-src)>=32: can copy with 32B blocks
>    (dst-src)>=16: can copy with 16B blocks
>    (dst-src)>= 8: can copy with 8B blocks
>    1/2/4: Generate a full-block fill pattern
>    3/5/6/7: partial fill pattern (16B block with irregular step)
> 

If this is something for your library for your compiler, then of course 
you are free to do anything you want here - standard library code does 
not need to be portable, but is free to use any kind of compiler "magic" 
it likes.  (For example, gcc has lots of builtins and extensions that 
are not targeted at normal code, but are targeted specifically at 
library writers.)

> There is a difference here between "_memlzcpy()" and "_memlzcpyf()" in 
> that:
>    the former will always copy an exact number of bytes;
>    the latter may write 16-32 bytes over the limit.

It may do /what/ ?  That is a scary function!

>>>
>>> Possible:
>>>    __MINALIGN_type__  //minimum allowed alignment for type
>>
>> _Alignof(type) has been around since C11.
>>
> 
> _Alignof tells the native alignment, not the minimum.

It is the same thing.

> 
> Where, _Alignof(int32_t) will give 4, but __MINALIGN_INT32__ would give 
> 1 if the target supports misaligned pointers.
> 

The alignment of types in C is given by _Alignof.  Hardware may support 
unaligned accesses - C does not.  (By that, I mean that unaligned 
accesses are UB.)

> 
========== REMAINDER OF ARTICLE TRUNCATED ==========