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: Mon, 8 Jul 2024 12:39:02 -0500
Organization: A noiseless patient Spider
Lines: 112
Message-ID: <v6h8ao$ur1v$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> <v6b0jv$3nnt6$1@dont-email.me>
 <87h6d2uox5.fsf@nosuchdomain.example.com> <v6d779$6rk5$2@dont-email.me>
 <v6e76u$c0i9$1@dont-email.me> <v6esqm$fian$2@dont-email.me>
 <v6f7vg$hgam$1@dont-email.me> <20240707164747.258@kylheku.com>
 <v6gl83$s72a$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 08 Jul 2024 19:40:40 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="cd76dc2001c036cabec0a5093b6250d9";
	logging-data="1010751"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19NIoziV5luq2bI1zOkXKp4092rEvIjERc="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:jYIHjayZW9jSSgZLmMnTv1FqT/o=
In-Reply-To: <v6gl83$s72a$1@dont-email.me>
Content-Language: en-US
Bytes: 5570

On 7/7/2024 11:28 PM, James Kuyper wrote:
> On 7/7/24 20:02, Kaz Kylheku wrote:
> ...
>> Ritchie's B language had arrays which contained a pointer to their
>> first element. Via a hack, it was possible to relocate an array.
>>
>> In C, such a thing is not simply not required; it is ruled out
>> by the detailed semantic description of arrays.
>>
>> The entire representation of an array of size N elements of type
>> T is contained in the memory block that is sizeo(T)*N bytes wide.
>>
>> If you copy that block, you have a fully functional copy of the array.
>> No extra pointer needs to be set up with the correct value.
> 
> An implementation which took the following code:
> 
> int array1[5], array2[5];
> memcpy(array2, array1, sizeof array1);
> 
> and translated it into machine code that was the equivalent of
> 
> int array1[5], array2[5];
> int *_p1 = &array1[0], *_p2 = &array2[0];
> memcpy(_p2, _p1, sizeof array1);
> 
> would not violate any of the requirements you mention. The key point is
> that when you copy the contents of an array to a new location, you
> wouldn't want to copy the implicit pointer - it would point at the wrong
> location. And if the destination is itself declared as an array, it
> would already have an implicit pointer that pointed at the correct location.
> 

Pretty much.


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


>> Furthermore, to dynamically allocate an array, you need only
>> provide sizeof(T)*N bytes of storage, and not a bit more.
>>
>> There is simply nowhere in the representation of an array where
>> a pointer could hide that is part of the representation.
> 
> Allocated memory is already accessed through a pointer; there would be
> no corresponding need to create an implicit one when there's already an
> explicit one.


Yes.

Similarly:
   int a[10];
   int *p;
   p=a;
Merely copies the value of the implicit pointer to the explicit one.

The 'a', from the compiler's POV, is basically a pointer, that just 
happens to be initialized to point to a piece of memory holding 10 integers.


In the IR, there are some instructions to signal that memory should be 
reserved for an array or object, eg:
   INITARR     dst, size
   INITOBJ     dst, type
   INITOBJARR  dst, type, size

Though, the actual space reservation and initialization is done in the 
prolog, and these ops more exist to signal that space should be reserved.

In some of my VMs, these sort of ops perform the memory reservation as 
well. In these VMs, local variables could be seen as an array of 
pointer-sized values (where, say, most types reserve 1 element, but 
128-bit types reserve 2 elements).

But, if one is familiar with the Java JVM, how all this behaves 
shouldn't be too hard to figure out. Well, except that in this case, 
locals, arguments, and temporaries, existed as 3 arrays, rather than a 
single array. In the BS2VM, it was two arrays: one for arguments, and 
another for locals and temporaries.

....