Path: ...!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: Sun, 15 Sep 2024 21:40:59 +0200
Organization: A noiseless patient Spider
Lines: 266
Message-ID: <vc7d8b$2a405$4@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>
 <vc1lqs$u8cm$1@dont-email.me> <vc3apo$1b7j3$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 15 Sep 2024 21:41:00 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0f814bd11c9fbe5b78942ec153f06f57";
	logging-data="2428933"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+d+uWnIAKfKFCMV76uUgUZ192JCWTX4y8="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:xmG54a85+m80hnwKX9W1LkMNaZA=
In-Reply-To: <vc3apo$1b7j3$1@dont-email.me>
Content-Language: en-GB
Bytes: 11228

On 14/09/2024 08:34, BGB wrote:
> On 9/13/2024 10:30 AM, David Brown wrote:
>> 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>


>>> 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.
>>
> 
> Until VS2013, the most one could really use was:
>    // comments
>    long long
> Otherwise, it was basically C90.
>    'stdint.h'? Nope.
>    Ability to declare variables wherever? Nope.
>    ...

Nonsense.

MS basically gave up on C and concentrated on C++ (then later C# and 
other languages).  Their C compiler gained the parts of C99 that were in 
common with C++ - and anyway, most people (that I have heard of) using 
MSVC for C programming actually use the C++ compiler but stick 
approximately to a C subset.  And this has been the case for a /long/ 
time - long before 2013.

> 
> After this, it was piecewise.
>    Though, IIRC, still no VLAs or similar.
> 

That I believe.

> 
>> 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.
>>
> 
> FWIW:
> I had been adding parts of newer standards in my case, but it is more 
> hit/miss (more adding parts as they seem relevant).
> 

Clearly your own compiler will only support the bits of C that you 
implement.  But I am not sure that it counts as a "serious, general 
purpose C compiler in mainstream use" - no offence implied!

> 
>>>>
>>>>>    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.
>>
> 
> Say, you are using a target where you can't use GCC or similar.

Which target would that be?  Excluding personal projects, some very 
niche devices, and long-outdated small CISC chips, there really aren't 
many devices that don't have a GCC and clang port.  Of course there 
/are/ processors that gcc does not support, but almost nobody writes 
code that has to be portable to such devices.

And as for optimising compilers, I used at least two different 
optimising compilers in the mid nineties that inlined code 
automatically, before using gcc.  (I can't remember if they inlined 
memcpy - it was a long time ago!).  Optimising compilers are not a new 
concept, and are not limited to gcc and clang.

> 
> Say:
> BJX2, haven't ported GCC as it looks like a pain;
>    Also GCC is big and slow to recompile.
> 
> 6502 and 65C816, because these are old and probably not worth the effort 
> from GCC's POV.
> 
> Various other obscure/niche targets.
> 
> 
> Say, SH-5, which never saw a production run (it was a 64-bit successor 
> to SH-4), but seemingly around the time Hitachi spun-out Renesas, the 
> SH-5 essentially got canned. And, it apparently wasn't worth it for GCC 
> to maintain a target for which there were no actual chips (comparably 
> the SH-2 and SH-4 lived on a lot longer due to having niche uses).
> 

It would be quite ridiculous to limit the way you write code because of 
possible limitations for non-existent compilers for target devices that 
have never been made.

> 
>>> 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.
>>
> 
> I can think of a few.
> 
> Most often though it is in things like data compression/decompression 
> code, where there is often a lot of priority on "gotta go fast".
> 

I still cannot see any situation where it would be relevant.  If I need 
to read 4 bytes of memory from an address, and don't know if the address 
is uint32_t aligned or not, I would use memcpy().  The compiler would 
know if unaligned 32-bit reads are supported or not for the target, or 
if it is faster to use them or use byte reads.  That's the compiler's 
job - I'm the programmer, not the micro-manager.

And if I know that for a particular target there are particular 
instructions that could be more efficient but are unknown to the 
compiler (perhaps there are odd SIMD instructions), and it is worth the 
effort to use them, then I would be writing that code for the specific 
target.  That's target-specific conditional compilation, and I still 
have no need to know if the target can access misaligned data.

> 
>>> 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!
>>
> 
> This is why the latter have an 'f' extension (for "fast").
> 

I can accept that there are cases (such as you describe below) where 
this might be useful, but I would not be identifying it just with an "f".
========== REMAINDER OF ARTICLE TRUNCATED ==========