RFC: Arrays

[Qix-]

TODO

[corbin-r]

@Qix-
Possible methodologies for arrays could be like how Swift does them:

 func foo([Int32] fish): Int {}

Incasing the type could be easier than parsing the variable name in a C++ style syntax:

 int foobar[];

I say "could be easier" because then the compiler deduces the "type" as an array in place of the variable name, and because the variable is assigned to the given type, all the compiler would have to is draw var name to type (which would be defined as an array).

Could be faster? Definitely would require testing.

[Qix-]

Yep that's how I plan to do it. Just gotta get around to writing the RFC out.

a [i32] = [1, 2, 3, 4]
b [str] = ["hello", "world"]
c [[f128]] = [[1234.56, 19999991.22], [67776.3, 19984.5555]]

[Qix-]

@PolyGN maybe you have some ideas about this.

One of Arua's goals is to be very compatible with C-family code without making sacrifices. One of the ideas I had was to use the concept of negative pointer offsets as metadata information, reducing lea-type instructions.

Arua supports syntax such as

foo [u32] = [1, 2, 3, 4, 5]
bar u32 = foo.length # 5

This would allow for configurable dynamic bounds checking as well as increased performance for strlen()-type operations (since alias str8 as str and typedef [u8] as str8, for instance).

This, however, limits arrays to a specific length and guarantees an overhead of at least n bytes where an array's maximum length is 2^(8n)-1 elements long. Theoretically, n could be the equivalent of sizeof(void*) since the addressing space of a program usually doesn't exceed that amount unless the system has PAE capability (such as IA-32 processors). What's more is that if the user wanted to disable such checking, the overhead would still be necessary if they intended to use arr.length.

The tradeoffs are very debatable.

Anyway, the idea is that an array is allocated (malloc(n + e * s) + n where n is sizeof(array.length), e is the number of elements and s is sizeof(element)). For any .length references, n is subtracted from the pointer and dereferenced as the length. Since length lookups are less likely and regular reads are more likely, we no longer have to add n to our offsets when looking up elements, granting a little bit of a micro-optimization.

Plus, Arua code that must call into C can simply pass the array and array.length as parameters where necessary and array will resolve to the pointer of the data itself.

tl;dr With negative pointers for metadata, we remove lea/add-type instructions for regular reads and writes since there is a length value prefixed to the datatype, and shift them to the lesser-called .length reads and the eventual freeing of the memory.

Hopefully that made sense.