Path: ...!weretis.net!feeder8.news.weretis.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: Sun, 15 Sep 2024 18:54:09 -0500
Organization: A noiseless patient Spider
Lines: 486
Message-ID: <vc7s5b$2empo$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>
 <vc1lqs$u8cm$1@dont-email.me> <vc3apo$1b7j3$1@dont-email.me>
 <vc7d8b$2a405$4@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 16 Sep 2024 01:55:24 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="76dde52cc591d309c4359b36d46257d9";
	logging-data="2579256"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18L97/GmQMIB6y/ZWK8cmGSsQd+fcB7vyA="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:NKNtapTynM6qLh534zhlRY3KlTw=
In-Reply-To: <vc7d8b$2a405$4@dont-email.me>
Content-Language: en-US
Bytes: 18102

On 9/15/2024 2:40 PM, David Brown wrote:
> 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.
> 

Go and try to write C with variables not declared at the start of a 
block in VS2008 or similar and see how far you get...


While, it may work in C++ mode, it did not work in C mode.

IIRC, the ability to declare variables wherever got added in VS2013.
Looks like 'stdint.h' got added in VS2010.

By around VS2018, most of C99 was added, apart from the parts they 
didn't add.


Checking, seems VS2022 has a few parts of C11 as well, such as 
"threads.h" and similar.


>>
>> 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!
> 

It compiles a lot of the code I throw at it, though occasionally steps 
on holes or bugs.

As for C99 stuff:
   VLAs, implemented but a little buggy;
     Internally, they are handled as reference types;
     The bounds are effectively encoded in an object header.
   _Complex, not well tested, but theoretically implemented.
     _Imaginary is treated as functionally equivalent to _Complex.

So:
   _Imaginary double ig0;  //will take 16 bytes.

For C11 stuff, didn't bother with _Generic or similar for now.
   Did add C11 threads and similar (rather than pthreads for now).


It does have a fairly limited optimizer, and will tend to mostly compile 
code pretty much as-written. Usual focus was on trying to make it 
"stable enough" (and reducing the amount of "obvious inefficiencies", 
*1) rather than chasing elaborate optimizations.

*: Say:
   y=(int)x;
Being handled as a single operation rather than multiple operations, ...

It will evaluate constant expressions, but generally will not generally 
propagate constants or pattern-match any non-trivial expressions.


>>
>>>>>
>>>>>>    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.
> 


It also depends on what one considers optimizing.

But, like:
   Allocates variables into registers;
   Evaluates expressions involving constants;
   Turns "memcpy()" into inlined loads/stores in some cases;
     Essentially treating it like a builtin function.
   ...


Well, at least BGBCC does this much.


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