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

On 7/18/2024 8:00 AM, Bart wrote:

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.
 

Basically what was going on in this case. Not going to redesign how structs are implemented, or the ABI rules, etc, simply because of a bug. One needs to fix the bugs...
Whole reason a lot of this exists was, I started out fiddling with the SH-4 ISA design, but SH-4 wasn't fast enough.
Could have gone with RISC-V, but RISC-V wasn't fast either, and initially I didn't like it, though things ended up mutating in a direction where my current ISA design has more in common with RISC-V than it does with SH-4...
Though, it also has some features in common with SH-5 instead (where SH-5 was a replacement ISA with 64 GPRs and fixed-length 32-bit instructions, rather than 16 GPRs and 16-bit instructions).
Mine is 32|64 GPRs and variable-length instructions (16/32/64/96 or 32/64/96). Though, has annoyingly split into two sub-variants (because there was no good way to fit everything I wanted into a 32-bit base instruction and still have sufficient opcode space).
Part of why my effort still hangs on, is because it still tends to have a roughly 20-50% per-cycle performance advantage over RISC-V (depending on situation).
Though, whether 20-50% is enough to matter is debatable.
So, 50 MHz BJX2, for general use, would be ~ 66 or 75 MHz RISC-V.
Assuming all other things are equal, and it is a generic plain-C integer workload...
Dhrystone is a little closer to break-even though (and depends a lot on compiler settings; RV64G will win at Dhrystone with default compiler settings in my case, which are more tuned to be conservative than fast; and there is a whole lot of stuff that is still optional/experimental and enabled by compiler flags).
In some niche edge cases (such as OpenGL style software rasterization), performance per clock seems to beat out x86-64 by a factor of around 5x.
And, seemingly, older 32-bit x86 by around 8x to 10x.
It seems to be around 4x vs RV64G.
Though, this is unfair as in my case this is with ASM and various helper instructions.
Though, higher clocked x86 will run circles around my ISA with Doom and Quake performance.
Similarly, RV64G + Quake does well in terms of performance in terms of Quake's software renderer (on my ISA, the Quake software renderer is actually slower than software-rasterized OpenGL).

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

I suspect 'const' structs are not really a thing in C.
Luckily at least, it is easy to detect that a by-value struct will not be modified anywhere in a function.
Less easy to reliably detect that it won't be modified in the immediate future.
So, I have ended up needing to fall back to slightly more conservative semantics here. Namely, copy on assignment. Doesn't change the underlying ABI behavior though (which is to internally behave as-if they were all being essentially handled using pointers and then memcpy'ed as-needed).

>
>

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.
 

The Hitachi version of the SH-4 ABI also had the same issue here as the SysV AMD64 ABI.
Apparently, Microsoft saw these and was like, "We will do our own ABI".
And, my own ABI was mostly following similar patterns to the MS ABIs (just with more register arguments, namely 8 or 16 rather than 4; but, BJX2 has more GPRs than either x86-64 or SH-4, and it makes sense to use 1/4 of the GPRs for argument passing).
Seemingly GCC was more like, "We will take the original ABI design and file off some of the sharp edges". And, the RISC-V ABI seems to be based on a "How did GCC implement the SysV AMD64 ABI?"
Namely passing structures in registers but in more or less the same form they would be stored in memory; or by memory on the stack if it doesn't fit in registers.

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

Yeah.
Though, the rules for passing are mostly (assuming not out of arg GPRs):
   1-8 bytes, 1 GPR;
   9-16 bytes, 2 GPRs, even numbered pair;
   17+, pointer/reference.
     Maybe stack or heap;
     For by-value structs, must be valid/non-NULL.
Returning is similar, except that for the 17+ case, the caller passes the pointer of the location to return the struct's contents into (and if missing a prototype, the call is probably going to violently explode).
For smaller cases, the struct will be returned in 1 or 2 GPRs (as with integer arguments).
Only even pairs are allowed for 128-bit passing, so if an odd number of register arguments had been used thus far, the register goes unused (also implicitly they will have 128-bit alignment on stack if one runs out of registers).
Say, for example:
   typedef struct { float x, y, z; } fvec3_t;
   ...
   fvec3_t InterpBilinFV3(
     fvec3_t a, fvec3_t b, fvec3_t c, fvec3_t d,
     float x, float y);
Will use 10 argument registers (or 8 args + 2 stack, if using the 8-argument ABI variant).
Where, say:
   first register holds:
     (31: 0): x
     (63:32): y
   Second register holds:
     (31: 0): z
     (63:32): pad/zero
As with the MS ABIs, in my current mainline ABI variants, there is a designated spill space equal to the number of argument registers (64 or 128 bytes).
If any stack arguments are used, they appear after this spill space.
Stuff, as it happens in the compiler's generated code, follows similar patterns to the ABI.
However, the ABI with 32-bit pointers omits this spill space. Though, this is intended for microcontroller like uses, but using my current ISA for a microcontroller doesn't make much sense and RV32I (32-bit RISC-V) seems to be a more sane option for this use-case (an RV32I core can be implemented more cheaply).
So, using my own ISA designs for microcontroller style uses has mostly fizzled out as it is cheaper/easier to just use RISC-V for these.

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.

Yeah.
My compiler is still a lot more naive than the sorts of "cleverness" that GCC tends to use.