Implement proper support for arrays

[PhilippvK]

[jokap11]

Do you think this should have a place in develop?
I would only implement an array consisting of constant for the moment, similar to Minres/CoreDSL#114

I would give it a declaration_plus_definition label, but this is basically non-canon
Have you already started work on this? Because I need it anyways.

(Edit) Code removed as the Parser within CoreDSL2.g4 already supports a List Initializer

Later enhancements:
Proper internal array state support to also allow (concurrent) write access

[PhilippvK]

Thanks for bringing this up!

I also need to have array support im M2-ISA-R. But in terms of relevance I would recommend the following sub-tasks:

• Support arrays of constants (declared and defined in archtitectural state or behavior)
• Support writable arrays in both architectural state and instruction/function behavor -> Current workaround is using a register declaration instead of an array, however this has some disadvantages (not signed/unsigned,…)
• Support multi-dimensional arrays (2D,…) for both constants and temporaries.
• Support structs and unions (Support structs and unions #55) including arrays and proper padding/packing

[jokap11]

Okay I think the prioritization makes sense.
Regarding TypeInference. Do you think we should allow arbitrary sizes within an array or should this throw something in the validator/type inference

E.g.:

static const signed<16> immem[4] = {16'b1, 15'b2, 14'b3, 13'b4};

As we would have her implicit size extension again.
Should the Size of immem be 4*16?

[PhilippvK]

I have looked into support for unions & strucs 3+ years ago (https://github.com/tum-ei-eda/M2-ISA-R/compare/coredsl2...PhilippvK:M2-ISA-R:feature_support_struct_union?expand=1) but got stuck because auf the missing/broken handling of array initializations and multi-dimensional arrays. I don’t think that the changeset will be helpful for implementing array support though.

The main aspects which have to be considered are:

• How initialization data is stored: Just a (nested) python array?
• How multi-dimensional arrays are handled: single Memory or multi-level memories?
• Can an array have children of different lengths?
• Do we need to support arrays of aliases/pointers?
• Aliases of (multi-dimensional) arrays should be support or not (I think just register aliases would be fine)
• How the ETISS backend would need to change

[PhilippvK]

As we would have her implicit size extension again.

I thinks the minres validator only complaints for implicit truncation. I thinks implicit extends should be fine. For the const init values smaller than the array datatype we should sign/zero extend before storing.

Should the Size of immem be 4*16?

This would imply that immem is not a reference but the data itself. In my poinion immem is just a a „reference“ without a size, immem[i] has size 16, immem[i+offset:i] has size (offset+1)*16 bits.

However this assumes that the type inference only counts the bits of all array elements. Maybe it would make more sense to add a num_lanes property to the DataType class and instead set the infered types as follows:

• immem[i] -> i16
• immem[i+3:i] -> v4i16

[jokap11]

Thank your for the input.
I would actually try to differentiate between the terms num_lanes terms and shape
I connect to num_lanes the actual available HW unit/lanes, while the array might be typically bigger than this.
Otherwise I agree to add a Shape parameter to an object. So If len(shape) = 0, we have one element and otherwise an array, that might propagate accordingly. Most Rules will anyways only increase the size dimension, as we only use Element-wise operations, but Indexing?
All other more complex features (but multi-dimensional) are just ignored for now

[jokap11]

I have taken a closer look at the typing system in the metamodel and identified several structural limitations and design choices that may become restrictive. In my view, a refactoring is necessary.

The most significant issue is the absence of a unified Symbol abstraction within the architecture that carries an explicit type attribute. Instead, the current design relies on multiple derived classes of SizedRefOrConst (see: https://github.com/tum-ei-eda/M2-ISA-R/blob/coredsl2/m2isar/metamodel/arch.py#L53
). This results in a class hierarchy that favors inheritance where composition would likely be more appropriate.

I propose such a structure to make future Extension a lot less hassle:

Symbol(name, type)
Type = PrimitiveType | IntegerType | TensorType |  ...

class Symbol:
    def __init__(
        self,
        name: str,
        typ: Type,
        mutable: bool = True,
        value=None, # Compile Time information
        storage=None,
    ):
        self.name = name
        self.type = typ
        self.mutable = mutable

        # optional: only for constants/literals
        self.value = value

        # optional: backend info (register, memory, etc.)
        self.storage = storage

The only downside is that every ExprVisitor/Mutator needs a refactor, but might lead to less headaches in the furuture
@PhilippvK What do you think?

[jokap11]

Will be pushed onto this:
https://github.com/tum-ei-eda/M2-ISA-R/tree/meta_type_refactor

Should I rebase/move to another branch as base?

EDIT: I have rebased to the last develop state from develop-fixes, to easy future merging