Converting types

[VictorGerin]

In this example i'm trying to "change the type" of the arrgument but have loking around and not found a solution :/,
any one have ideias to solve this ?

#subruledef  reg
{
    R0   => 0x01`4
    R1   => 0x02`4
    R2   => 0x03`4
    R3   => 0x04`4
    R4   => 0x05`4
    R5   => 0x06`4
    R6   => 0x07`4
}

#ruledef ; CPU instructions
{
    ldi {rd: reg}, {val: i8} => val @ rd @ 0b1000
}

#subruledef reg16
{
    R01  => 0x01`4
    R23  => 0x03`4
    R45  => 0x05`4
}

#ruledef ; CPU instructions 16bits
{
    ldi16 {rd: reg16}, {val: i16} => asm {
        ldi {rd}, ({val} & 0xFF)`8                   ;trying here change the type reg16 to reg
        ldi {rd+1}, (({val} >> 8) & 0xFF)`8          ;trying here change the type reg16 to reg
    }
}

[VictorGerin]

I was looking the examples
https://github.com/hlorenzi/customasm/blob/main/tests/expr_asm/ok_subrule_morph.asm
this is the closest that i found, but yet is not what i need

For what i test here custom asm uses the label to derive the value
So if i create a reg16 R0 instead of R01 in this case it should work.

but if i want for the R01 be a diferent value of 0x01`4 i can't

[hlorenzi]

That's correct: since reg16 and reg have different rules, you can't transform one into the other (e.g. R01 does not exist in reg). Your asm block would essentially be invoking ldi R01, ({val} & 0xFF) which isn't a valid instruction according to your ruledefs.

One way you could fix this is to create an alias for your ldi instruction which takes a raw integer value for the register argument:

#ruledef ; CPU instructions
{
    ldi     {rd: reg}, {val: i8} => val @ rd @ 0b1000
    ldi.raw {rd: u4},  {val: i8} => val @ rd @ 0b1000
}

Then, you may change your 16-bit ruledef to:

#ruledef ; CPU instructions 16bits
{
    ldi16 {rd: reg16}, {val: i16} => {
        rdRaw = rd
        asm {
            ldi.raw {rdRaw},   ({val} & 0xFF)`8
            ldi.raw {rdRaw}+1, (({val} >> 8) & 0xFF)`8
        }
    }
}

The rdRaw variable assignment is needed, otherwise the assembler would still be trying to do syntax substitution inside the asm block.
This is a bit of a shortcoming of the current system, and I think it deserves a better solution in the future.