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