Re: Computer architects leaving Intel...

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.
Things it doesn't do though:
   Loop unrolling;
   Inline functions;
   ...
There is a partial feature to cache member loads and array loads within a basic-block, but will flush any such cached values whenever a memory store happens.
Say:
   i=foo->bar->x + foo->bar->y;
Will cache and reuse the first foo->bar.
But, if you do:
   *ptr=0;
Or:
   foo->z=3;
It will flush any memory of the cached values (unless the pointers are 'restrict').
There is an option to disable this caching though (at which point it will always do each member load). But, unlike TBAA, this optimization is less prone to break stuff.
It also has a special feature than small leaf functions which can fit entirely in scratch registers may skip creation of a stack frame.
But, I can note that even with these limitations, BGBCC+BJX2 still seems to be beating RV64G + "GCC -O3" in terms of performance in my tests (well, mostly because clever compiler can't beat ISA limitations).

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

Hitachi did release an ISA spec for SH-5 at least (and it might have worked OK, if Renesas had pushed "upwards" rather than focusing almost exclusively on the small embedded / microcontroller space).
But, at present, people trying to worry about portability to things with non-power-of-2 integers, non-8-bit bytes, non-twos-complement arithmetic, etc, has a similar level of validity (or non-validity) to writing code for ISA's which never saw a release in "actual silicon".
In cases where I am targeting something like x86-64/ARM/RISC-V/... I am generally using GCC, Clang, or MSVC for this.
Ironically, BJX2-XG2 did end up kinda like SH-5 in some areas, but ironically SH-5 had a cleaner encoding scheme...

>

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.
 

If the compiler is naive (wrt inline memcpy):
   memcpy(&v, cs, 8);
   rl=(v>>4)&15;
Needs 5 instructions, but:
   v=*(uint64_t *)cs;
   rl=(v>>4)&15;
Uses 3 instructions.
Having the compiler turn the former into the latter is possible, but would require more complex pattern matching, and would likely need to be handled in the frontend (rather than in the function-call operation) in the backend.

>

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

OK.

There are cases where it may be desirable to have the function write past the end in the name of speed, and others where this would not be acceptable.
>
Hence why there are 2 functions.
>
>
The main intended use-case for _memlzcpyf() being use for match- copying in something like my LZ4 decoder, where one may pad the decode buffer by an extra 32 byes.
>
Also my RP2 decoder works in a similar way.
>
>

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

>
Not necessarily, it wouldn't make sense for _Alignof to return 1 for all the basic integer types.

 Of course it makes sense to do that, on targets where an alignment of 1 is safe and efficient.
 

Tradition dictates that struct members are pad-aligned aligned to their native alignment (usually equal to the size of the base type), unless the struct is 'packed'.
An implementation where all structs are packed by default could have unforeseen consequences...
Presumably, _Alignof would give the same alignment as would appear in structs or similar.

But, for" minimum alignment" it may make sense to return 1 for anything that can be accessed unaligned.
>

 Again, I see no use for this.
 

The main alternatives:
Detect target architecture and "know" whether the architecture is unaligned-safe (ye olde mess of ifdef's);
Have a global PP define that applies to all types, but this doesn't allow for cases where some types are unaligned safe but others are not.
One possibility could be __minalign__(type), but (unlike doing it with preprocessor defines), one could not likely use it in preprocessor expressions.
#if __MINALIGN_LONG__==1
...
#else
...
#endif
Works, but:
#if _Alignof(long)==1
...
Poses problems, as generally the preprocessor is not able to evaluate things like this.

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

>
The point of __MINALIGN_type__ would be:
If the compiler defines it, and it is defined as 1, then this allows the compiler to be able to tell the program that it is safe to use this type in an unaligned way.
>

 For what purpose?
 

Probably for unaligned deref's on targets where "memcpy()" is a less desirable option (say, if it takes several additional CPU instructions).

This also applies to targets where some types are unaligned but others are not:
Say, if all integer types 64 bits or less are unaligned, but 128-bit types are not.
>

 For what purpose?  And why do you want to worry about totally hypothetical systems?
 

Note that a lot of what I am describing here is true of BJX2.
It is also true of __m128 and similar in MSVC.
   __m128 v;
   v=*(__m128 *)someptr;
May explode if someptr is not 16-byte aligned, as it may emit a "MOVDQA" or similar (rather than MOVDQU).
But, in both cases, if "int *" or "long *" is misaligned, both are fine with it.
There may be other compilers in a similar camp.
But, then again, it is kinda hypothetical in the sense to claim that one can't cast and deref a pointer, since on most existing targets, it works without issue (except that on GCC one may also need to use 'volatile').

>
Most of this is being compiled by BGBCC for a 50 MHz cPU.
>
So, the CPU is slow and the compiler doesn't generate particularly efficient code unless one writes it in a way it can use effectively.
>
Which often means trying to write C like it was assembler and manually organizing statements to try to minimize value dependencies (often caching any values in variables, and using lots of variables).
>
>
In this case, the equivalent of "-fwrapv -fno-strict-aliasing" is the default semantics.
>
Generally, MSVC also responds well to a similar coding style as used for BGBCC (or, as it more happened, the coding styles that gave good results in MSVC also tended to work well in BGBCC).
>

 Note that MSVC most certainly does /not/ work like "gcc -fwrapv" - signed integer overflow is UB in MSVC, and it generates code that assumes it never happens.  There is an obscure officially undocumented (or documented unofficially, if you prefer) flag to turn off such optimisations.
 Last I read about it, they had no plans to do any type-based alias analysis, but nor did they rule out the possibility in the future.
 

I haven't seen any issues with MSVC and this sort of code usually works as expected...
But, a lot of times, one has to supply these options to GCC otherwise the code will break. So, it almost makes sense to assume these semantics as a default.
In the case of BGBCC, I decided to make these semantics the default as a matter of a policy decision.
There is some talk about pointer provenance semantics for C (apparently semi controversial), but admittedly thus far I don't fully understand the idea.