Re: technology discussion → does the world need a "new" C ?

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