Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.lang.c
Subject: =?UTF-8?Q?Re=3A_technology_discussion_=E2=86=92_does_the_world_need?=
 =?UTF-8?B?IGEgIm5ldyIgQyA/?=
Date: Sat, 6 Jul 2024 03:51:02 -0500
Organization: A noiseless patient Spider
Lines: 57
Message-ID: <v6b0jv$3nnt6$1@dont-email.me>
References: <v66eci$2qeee$1@dont-email.me> <v67gt1$2vq6a$2@dont-email.me>
 <v687h2$36i6p$1@dont-email.me> <871q48w98e.fsf@nosuchdomain.example.com>
 <v68dsm$37sg2$1@dont-email.me> <87wmlzvfqp.fsf@nosuchdomain.example.com>
 <v6ard1$3ngh6$4@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 06 Jul 2024 10:52:16 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d3c5ef1cde4e45ddc2826fbe07375cf5";
	logging-data="3923878"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+yg0ijow3D+Ze/v+mRgbyS49Rudrv2+hM="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:RB6Ov9HwzBOfOY5saNfC9sV/Qrc=
In-Reply-To: <v6ard1$3ngh6$4@dont-email.me>
Content-Language: en-US
Bytes: 3415

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.


....