typesystem: Support implicit upcast of binary and hexadecimal literals

[Jozott00]

I would like to discuss the current state about the implicit casting of hexadecimal constant literals.

Currently, binary and hexadecimal literals have a fixed type based on their width — e.g., 0x1234 is Bits<16>. This contrasts with decimal literals, which use the flexible Const type.
As a result, hex/bin literals don’t support automatic upcasting, which limits their usability in contexts expecting larger types.

E.g. the following code

memory MEM: Bits<64> -> Bits<8>
...
MEM(0x1000) := 0x00

will fail with

error: Type Mismatch
     ╭──[spec.vadl:109:5]
     │
 109 │     MEM(0x1000) := 0x00
     │     ^^^^^^^^^^^ Expected `Bits<64>` but got `Bits<16>`.
     │

This happens because the memory target expects a Bits<64>, while the hex literal like 0x00 is Bits<16>.
Using a decimal literal like 4096 works since it is treated as Const<4096> and can be upcasted. But for memory addresses, decimal literals aren’t a practical workaround.

The alternative is to add a manual cast to 64-bit. However, this decreases readability and is cumbersome.

firmware = {
    MEM<4>(0x1000 as Bits<64>) := 0x00000297  // auipc t0, 0x0
    MEM<4>(0x1004 as Bits<64>) := 0x02828613  // addi a2, t0, 40
    // this processor has no zicsr extension
    MEM<4>(0x1008 as Bits<64>) := 0x00000013  // addi x0, x0, 0
    MEM<4>(0x100c as Bits<64>) := 0x0202b583  // ld   a1, 32(t0)
    MEM<4>(0x1010 as Bits<64>) := 0x0182b283  // ld   t0, 24(t0)
    MEM<4>(0x1014 as Bits<64>) := 0x00028067  // jr   t0
    // store start_addr in memory (0x80000000)
    MEM<4>(0x1018 as Bits<64>) := 0x00000000  // lo32(start_addr)
    MEM<4>(0x1018 as Bits<64>) := 0x80000000  // hi32(start_addr)
    // we do not yet support a fdt
    MEM<4>(0x101c as Bits<64>) := 0x00000000  // lo32(fdt_addr)
    MEM<4>(0x1020 as Bits<64>) := 0x00000000  // hi32(fdt_addr)
  }

I think binary and hexadecimal literals should be implicitly upcasted like decimal ones. However, they seem to carry an implicit minimal size that doesn’t always match the minimal type needed for the value.
For example, 0x02 would have a minimal type of Bits<8>, but if treated like a decimal literal, it could be used in a context expecting Bits<4>, which might cause type truncation — something we probably want to avoid.

[AndreasKrall]

This is related to issue #79 and I assume we agreed on treating hex constants similar to decimal constants.