Specification and Checking of don't care bits in Instruction Encodings

[AndreasKrall]

In VADL it is necessary to specify the instruction behavior and the encoding. Currently it is not required and it is not checked if format fields are either used in the behavior specification or are set in the encoding of a concrete instruction. Take the following example:

  format TYPE_R : Bits<32> =
    { rd      : Index                       // destination register index rd
    , rs1     : Index                       // source register index rs1
    , rs2     : Index                       // source register index rs2
    , scale   : Bits<2>                     // scaling factor (currently unused)
    , func9   : Bits<9>                     // 9 bit function code
    , opcode  : OpCode                      // operation code
    }

  instruction ADD : TYPE_R =
    let res = R(rs1) as SIntR + R(rs2) as SIntR in
      R(rd) := res as Regs
  encoding ADD = { opcode = 63, func9 = 0 } // scale = 0 or none

In the example scale is neither used nor set to a fixed value. Should the type checker issue a warning, an error or is this a correct specification. Should it be possible to define don't care bits like scale = DontCare or an annotation [DontCare : scale] or is it required that unused bits always have to be set.

What is your opinion?

[Jozott00]

Are we talking about the fact that the format field has never been used in an instruction, or that not all instructions use the format field?

To mute warnings/compile errors, many languages use underscore _ as a placeholder for ignored values.

[AndreasKrall]

Are we talking about the fact that the format field has never been used in an instruction, or that not all instructions use the format field?

To mute warnings/compile errors, many languages use underscore _ as a placeholder for ignored values.

I updated the discussion to make it clear, that this discussion is about a single instruction, not about all instructions which use this format field. In my opinion we should issue an error and require that all fields are used either in the behavior or the encoding.

I like the idea to use the underscore _. We use it already in match and it fits perfectly to the planned extension where we use the question mark ? to define fields for automatic encoding. So the correct specification in this example without issuing an error is:

  instruction ADD : TYPE_R =
    let res = R(rs1) as SIntR + R(rs2) as SIntR in
      R(rd) := res as Regs
  encoding ADD = { opcode = 63, func9 = 0, scale = _ } // scale is not used in behavior
  encoding ADD = { opcode = 63, func9 = ?, scale = _ } // automatic encoding of func9

A small drawback is, that _ and ? are not valid expressions. So if we want to use macros in the encoding specification, we only can use Encs for the whole encoding element, but not Ex after the equal symbol =.

[AndreasKrall]

In the meeting on May 7th we agreed to implement the version with underscore _ in the encoding specification and it will be checked by the decoder generator.