Field value that catches unspecified values

[flaviojs]

Hi,

I'd like to be able to set a "default" field value that catches unspecified values.
Not sure about the syntax, maybe Default(_) or Default = _.

Here is an example that would catch unknown values for easier error reporting:

register_bitfields![u16,
    #[doc = "Host Controller Version Register (Offset 0FEh RO)"]
    pub HostControllerVersion [
        #[doc = "Specification Version Number"]
        SPEC  OFFSET(0) NUMBITS(8) [
            #[doc = "SD Host Specification Version 1.00"]
            Version100 = 0,
            #[doc = "Unknown Specification Version"]
            Unknown(_)
        ],
        #[doc = "Vendor Version Number"]
        REV  OFFSET(8) NUMBITS(8) [],
    ],
];

It could also be the opposite use case, where we capture the values that really matter in the "default" field:

register_bitfields![u16,
    pub Example [
        FIELD  OFFSET(0) NUMBITS(8) [
            Reserved = 0b11111111,
            Value(_)
        ],
    ],
];

Note that this enum cannot be #[repr($valtype)] since it will contain an entry with a $valtype inside (probably).
The comment of the repr indicates it's not a problem: // so that values larger than isize::MAX can be stored

---

Since this is about the field values section, note that I also mentioned here another use case for that section (representing a subregister).
No idea how the debug text should be in that particular use case, so didn't create an issue.

[ppannuto]

I'm not sure I entirely understand the value here. One of the key concepts of Tock Registers is allowing for strong typing information for registers and bitfields. On the "construction" path, this means you can only create/write known, well-defined values. On the "read" path, you will either get a valid Some(...) back which is a known, defined type for the current hardware state, or None, which is equivalent to the catch-all Unknown here (and you can still "escape" this strong typing by reading the underlying storage as a raw int-like type).

I think it would be anti-pattern to have type like Unknown, since there's nothing meaningful to be done with that type--it carries no semantic meaning, and it should never be constructed by code [since if there was a semantically meaningful reason for the underlying value, the bitfield should define it as a type!].

That said, I could easily be missing/misunderstanding something here, could you articulate the use case for such a catch-all type a bit more clearly?

[flaviojs]

If strong typing is a requirement then this is probably a no-go since rust enum construction is always public.
The value of Unknown(_) can be restricted to always be different from the other values in TryFromValue::try_from_value, but not in Enum::Unknown(123).

If there is semantic meaning or not depends on the use case, for the SPEC case there are indeed other spec values but this register set is done according to a specific spec version (which only includes values up to that version), and some registers are replaced by other registers in other spec versions.
The unknown values are valid but not included in the spec being followed, so for me being "unknown" or "not supported" or "reserved" is the real semantic meaning of those values. Note that this field belongs to a read-only register so it won't be constructed.

Ideally I would be able to use the type directly instead of making/using a different type.

impl SomeStruct {
    pub fn spec(&self) -> HostControllerVersion::SPEC::Value {
        self.regs.hcv.read_as_enum::<HostControllerVersion::SPEC::Value>(HostControllerVersion::SPEC).unwrap()
    }
}

fn other_code(x: &mut SomeStruct) {
    match x.spec() {
        HostControllerVersion::SPEC::Value::Version100 => do_spec_v100_stuff(x),
        HostControllerVersion::SPEC::Value::Unknown(spec) => {
            error!("Unknown SDHC spec 0x{spec:02x}, please use the correct driver");
            // possible alternate code with PIO only, which is the same in all specs
        }
    }
}

For the second case, the spec has a "Data Timeout Counter Value" field with 0b1111 being reserved and the other values represent some power of 2.
The spec also includes fields where 0 = "Get information via another method", like the maximum current where 1-255 is the current in 4mA steps, or the base clock frequency, etc.

register_bitfields![u32,
    pub Example [
        TIMEOUT_COUNTER  OFFSET(0) NUMBITS(4) [
            Reserved = 0b1111,
            PowerOf2From13(_)
        ],
        MAX_CURRENT  OFFSET(4) NUMBITS(8) [
            OtherMethod = 0,
            _4mA(_)
        ],
        BASE_CLK  OFFSET(12) NUMBITS(6) [
            OtherMethod = 0,
            MHz(_)
        ],
    ],
];

Hmm, if the constructor problem could be fixed then a more explicit and clear approach would be to use ranges instead of a catch all _:

register_bitfields![u32,
    pub Example [
        TIMEOUT_COUNTER  OFFSET(0) NUMBITS(4) [
            Reserved = 0b1111,
            PowerOf2From13(0..=14)
        ],
        MAX_CURRENT  OFFSET(4) NUMBITS(8) [
            OtherMethod = 0,
            _4mA(1..=255)
        ],
        BASE_CLK  OFFSET(12) NUMBITS(6) [
            OtherMethod = 0,
            MHz(1..=63)
        ],
    ],
];

Anyway, this might be a simple case of perspective but for me the catch all values add semantic meaning.