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

On 7/6/2024 3:51 AM, BGB wrote:

On 7/6/2024 2:23 AM, Lawrence D'Oliveiro wrote:

On Fri, 05 Jul 2024 11:46:38 -0700, Keith Thompson wrote:
>

No, arrays are not pointers.

>
Except array indexing is designed to be indistinguishable from pointer
arithmetic.

 Yeah, and in the 1D case, an array can be seen as functionally an implicitly defined pointer with an assigned size and preassigned backing memory.
 Granted, C generally allows one to see the backing memory, but not the implicit pointer to said backing memory. I guess one could argue that if one can't take the address of it, it doesn't exist, but yeah...
 Kind of a similar feature with lvalue structs:
   An implicit pointer exists...
   But, C wont let you see it directly or take its address.
  But, I guess, if C did allow people to see these, it would add a whole lot of meta issues.
 Would also open up ABI issues, say, for ABI's which pass structs by copying rather than by reference (and hinder optimizations like passing structs by value in registers in cases where they fit into registers).
  Then again, I suspect in the wider ABI design space, it seems like passing/returning by-value structs by-reference is mostly a Microsoft thing... But, I also did it this way (well, along with the controversial decision of providing a designated spill space for register arguments).
 Did notice that always providing 128 bytes for a 16 argument ABI (*1) was a bit steep, so dropped it to 64 bytes / 8 args if:
   No called function uses more than 8 arguments;
   No vararg functions are called.
Does have the drawback that the functions are back to reserving 128 bytes as soon as any "printf()" calls or similar exist, which isn't particularly rare.
  *1:
   With 16 GPRs, there were 4 arguments (R4..R7);
   With 32 GPRs, it was 8 (R4..R7. R20..R23);
   With 64 GPRs, it is 8 or 16 (adds R36..R39, R52..R55 in the latter).
 Though, 32 GPRs seems near optimal for most programs. But, GL rasterization benefits a fair bit, mostly because it is interpolating over a lot of state, which otherwise turns into a whole lot of register spill-and-fill.
 

^ GL rasterization benefits a fair bit from having 64 GPRs available.
In effect, there are some loops where the working state within the loop would not otherwise fit in the available registers with a 32 GPR configuration.
Meanwhile, 16 isn't really enough in general, and results in higher levels of spill and fill for most code.
Though, it may make sense for the compiler to limit register use based on the relative register pressure of a function (saving/restoring too many registers may cost more than it saves in terms of register spill/fill; resulting in most functions still being limited to using the low 32 registers...).
But, register allocation is its own fun topic...

 ...