Using record variant for register mapping in Ada

It is OK to model a double usage register with a record variant:

type Capture_Compare_Selection is (Output, Input_TI1, Input_TI2, Input_TRC) with Size=>2;
for Capture_Compare_Selection use(Output=>0, Input_TI1=>1, Input_TI2=>2, Input_TRC=>3);

type TIM_Register_CCMR (CCxS : Capture_Compare_Selection := Output) is record
   case CCxS is
      when Output=>
         OCxFE:Boolean := false;
         OCxPE:Boolean := false;
         OCMx:Output_Compare_Mode := Frozen;
         OCxCE : Boolean := false;
      when Input_TI1 .. Input_TRC =>
         ICxPSC: Input_Prescaler := P_1;
         ICxFF: Timer_Filter := No_Filter;
   end case;
end record with Size=>8;
for TIM_Register_CCMR use record
        CCxS at 0 range 0..1;
        OCxFE at 0 range 2..2;
        OCxPE at 0 range 3..3;
        OCMx at 0 range 4..6;
        OCxCE at 0 range 7..7;
        ICxPSC at 0 range 2..3;
        ICxFF at 0 range 4..7;
end record;

My rationale is that this register (well, fragment of register) has a double usage, depending on the LSB bit; it looks quite like an Ada variant record.

Is there a downside to that or can I commit all the way to this kind of use?

Here is a primer on the documentation:

The full documentation is page 344 of doc RM0090 at ST Microelectronics (huge doc).

I don’t see any problem with your code in itself; this is exactly the sort of thing variant records are for.

I think the only problem with naming record components is that it can lead you into writing code that attempts to directly alter one component, relying on the compiler to do the necessary whole-register reads and writes (the reference document says in para 17.4 that write accesses must be 16- or 32-bits wide, read accesses must be 8-, 16-, or 32-bits wide). There were discussions on comp.lang.ada about the fact that Ada currently has no way to specify this requirement; AI12-0128 refers (for Ada 2020). GNAT now has the pragma/aspect Volatile_Full_Access.

Nevertheless, naming the components will produce much more writable, readable and verifiable code.

StackExchange Code Review Q#65368, answer score: 2