Path: ...!2.eu.feeder.erje.net!feeder.erje.net!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 04:23:06 -0500
Organization: A noiseless patient Spider
Lines: 76
Message-ID: <v6b2g4$3nnt6$2@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> <v6b0jv$3nnt6$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 06 Jul 2024 11:24:20 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d3c5ef1cde4e45ddc2826fbe07375cf5";
	logging-data="3923878"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+ORH0cqEKS4bxMRUs9Aeiii8edvVnfug0="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:jPW2UhxfrDKxefjmEhqgEzeyMWg=
Content-Language: en-US
In-Reply-To: <v6b0jv$3nnt6$1@dont-email.me>
Bytes: 4338

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

> 
> ...
> 
>