Vanillnya / ohdl

Oxidized Hardware Description Language
3 stars 1 forks source link

Referencing architectures in code #25

Open DasLixou opened 1 month ago

DasLixou commented 1 month ago

Imagine this:

entity MyEntity { }
mod a {
    arch RTL for MyEntity { }
}
mod b {
    arch RTL for MyEntity { }
}

Absolute Unique Paths

Imports and lookup are handled the same as for all the other types, entities and modules. This means that e.g. an RTL can only be defined once. We also can't allow having an arch name refer to multiple entities because then the end user might want to import a::RTL for EntityA, but b::RTL for EntityB. This would also make tracing the imports back way more complex.

use a::RTL;
use b::RTL; // ERROR: `RTL` already defined

arch .. {
    MyEntity(a::RTL) { // but I like the way they are refered to here.. and otherwise we could also introduce renaming on imports

    }
    MyEntity(b::RTL) {

    }
}

A downside of this is that multiple RTLs from different paths not having any overlapping entities still can't be refered to as by just RTL. You also can't make multiple RTL-named archs in the same module.

Absolute Overlapping Paths

Same as above, but now we allow having multiple overlapping imports making some stuff worse to trace back and identify.

use a::RTL;
use b::RTL; // We now allow this, because b::RTL might be for a completely else entity

arch .. {
    MyEntity(RTL) { // now the question is what RTL we use here?

    }
}

This has the upside of allowing something like this:

entity EntityA {}
entity EntityB {}
entity EntityC {}

mod first {
    arch RTL for EntityA {}
    arch RTL for EntityB {}
}
mod second {
    arch RTL for EntityA {}
    arch RTL for EntityC {}
}

use first::RTL for EntityB; // we could do a `for` syntax, which would check for overlapping archs with same entities.
use second::RTL for EntityA, EntityC;

Identifier per Entity

We don't import any arch. The name of an arch is unique in the whole compilation suite and is refered to by it directly. The example from above wouldn't compile, but it would for two different entities. A problem here is that when e.g. two libraries define a RTL arch for their own, it can't compile.

Work-bound identifier per entity

Same as above, but fixes the compilation problem by making it work-bound. e.g. work::RTL. Still not very tracable. Question is how that would work with multiple versions, reexports, etc.