Re: technology discussion → does the world need a "new" C ?

On 18/07/2024 13:41, David Brown wrote:

On 18/07/2024 12:05, BGB wrote:

The "magical auto dereferencing pointers" interpretation gives better performance, when it works. In this case, it didn't work...

 It's very easy to make high performance code if correctness doesn't matter!  Obviously, correctness is more important.

It is useful to explore ways of making some scenarios faster. Here there is simply a bug in one of those ways. But you don't just give up completely; you can try fixing the bug.

>
Sadly, there is no good way at the moment to know whether or not it will work, for now forcing the slower and more conservative option.

 I would think the simple test is that for data that is never changed (or not changed within the function), you can use a constant reference - otherwise you cannot.  It is not by coincidence that in C++, it is common to use pass by /const/ reference as an efficient alternative to pass by value for big objects.

You said the other day that my C compiler was wrong to do that: to use efficient pass-by-pointer for structs marked as 'const' in the function signature; they always have to be copied no matter what.

>
>

If "foo_t" is 2000 bytes long, then "foo_t temp" makes a 2000 byte space in your local variables (the stack, on virtually every platform) and "temp = arr[i];" does a 2000 byte memcpy().  The same thing applies if "foo_t" is 2 bytes long, or 2 megabytes long.  And if there is a stack overflow making "temp", that's the programmer's problem.
>

>
For now:
1 - 16 bytes, goes in registers, except when accessing a member where it needs to be in-memory; unless it is a SIMD type which is special and allows accessing members with the value still in registers.
>
17 bytes to 15.999K: Accessed by an implicit reference, uses hidden copying to mimic by-value semantics (not quite foolproof as of yet it seems).
>
16K and beyond, quietly turned into a heap allocation (with a compiler warning). Should otherwise look the same as the prior case.
>

 The normal system is that local objects are data on the stack - regardless of the size or type, scaler or aggregate.  Parameter passing is done by register for some types (for the first few parameters), or the stack otherwise.  Returns are in a register or two for some times, or by a stack slot assigned by the caller.  For struct parameters or return values, it can be efficient for the caller to pass hidden pointers, but that's not strictly necessary if you have a fixed stack frame layout.  (Struct parameters still get copied to the stack to ensure value semantics - the hidden pointer points to the stack copy.)
 Trying to have special cases for different sizes,

That's exactly what common 64-bit ABIs do. In fact the SYS V ABI is so complicated that I can't understand its struct passing rules at all.
(If I ever have to use that, I'd need to write test code for each possible size of struct, up to 100 bytes or so (past the largest machine register), and see how an existing compliant compiler handles each case.)
Here the context appears to be a custom ISA, so anything is possible.

You are trying to be too smart here, IMHO - the compiler's job is to let the programmer be smart.  It's always nice to have optimisations, but not at the expense of correctness.

That's an odd remark from a devotee of gcc. Your usual attitude is to let the programmer write code in the most natural manner, and let a smart optimising compiler sort it out.