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

On Tue, 9 Jul 2024 16:31:30 +0200
David Brown <david.brown@hesbynett.no> wrote:

On 08/07/2024 19:39, BGB wrote:

On 7/7/2024 11:28 PM, James Kuyper wrote: 

On 7/7/24 20:02, Kaz Kylheku wrote:
... 

 

 

I see no point in having implicit pointers, but I don't believe
that they are prohibited.
 

 
They mostly exist in a "sort of simpler to implement the compiler
this way" sense.
 
In the implicit pointer case, the compiler just treats it as-if it
were an explicit pointer. In this case, both are basically treated
as being roughly equivalent at the IR levels.
 
And, most of the code-generation stage doesn't need separate
handling for arrays and pointers, but can use combined
"ArrayOrPointer" handling or similar.
 
It had all seemed "obvious enough".
 
 
 
 
Similar reasoning for passing structs by-reference in the ABI:
   Pass by reference is easy to implement;
   In place copying and decomposing into registers, kinda bad.
 
Though, this one seems to be a common point of divergence between
"SysV" and "Microsoft" ABIs. Sometimes a target will have an ABI
defined, and the MS version was almost the same, just typically
differing in that it passes structs by reference and provides a
spill space for register arguments.
 

 
I don't think it is helpful that you keep mixing /logical/ terms with
/implementation/ terms.
 
In C, there is no "pass by reference" or "return by reference".  It
is all done by value.  Even when you use pointer arguments or return
types, you are passing or returning pointer values.  C programmers
use pointers to get the effect of passing by reference, but in C you
use pointers to be explicit about references.
 
Structs in C are passed by value, and returned by value.  Not by
reference.
 
The C standards don't say how passing structs around by value is to
be implemented - that is hidden from the programmer.  Usually ABI's
(which are also hidden from the programmer) specify the
implementation details, but some ABI's are weak in that area.
Generally, structs up to a certain size or complexity are passed in
registers while bigger or more advanced types are passed via
addresses (pointing to stack areas) in registers or the stack, just
like any other bigger types.  This is not "pass by reference" as far
as the C programming is concerned - but you could well call it that
at the assembly level.  Where the line between "passing in registers"
and "passing via addresses to space on the stack" is drawn, is
entirely up to the compiler implementation and any ABI requirements.
Some simpler compilers will pass all structs via addresses, no matter
how simple they are, while others will aim to use registers whenever
possible.
 
 
So if you have these structs and declarations :
 
struct small { uint16_t a; uint16_t b; };
struct big { uint32_t xs[10]; };
 
struct small foos(struct small y);
struct big foob(struct big y);
 
Then compilers will typically implement "x = foos(y)" as though it
were:
 
extern uint32_t foos(uint32_t ab);
uint32_t _1 = foos(y.a << 16) | (y.b);
struct small x = { _1 >> 16, _1 & 0xffff };
 
And they will typically implement "x = foosb(y)" as though it were:
 
extern void foob(struct big * ret, const struct big * xs);
struct big x;
foob(&x, &y);
>

It depends on the ABI. Newer ABIs tend to work like that. Older ABIs
often copy the [big] structure to parameters area on callie's stack.
With 16 or more registers I see no obvious performance advantage to
either method. The preference of newer ABIs appears to be a matter of
fashion.

 
This is not, as you wrote somewhere, something peculiar to MSVC - it
is the technique used by virtually every C compiler, except perhaps
for outdated brain-dead 8-bit microcontrollers that have difficulty
handling data on a stack.
 
And it is not really "pass by reference" or "implicit pointers", it
is just passing addresses around behind the scenes in the
implementation.