Warning: mysqli::__construct(): (HY000/1203): User howardkn already has more than 'max_user_connections' active connections in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\includes\artfuncs.php on line 21
Failed to connect to MySQL: (1203) User howardkn already has more than 'max_user_connections' active connectionsPath: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB
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:
References:
<871q48w98e.fsf@nosuchdomain.example.com>
<87wmlzvfqp.fsf@nosuchdomain.example.com>
<87h6d2uox5.fsf@nosuchdomain.example.com>
<20240707164747.258@kylheku.com>
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:
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.
....