Support stringize and concat in translate-c

[frmdstryr]

Macro concat and stringizing not currently supported by translate-c

EDIT: Updated example

Eg from core_cm7.h:

/**
  \ingroup    CMSIS_core_register
  \defgroup   CMSIS_core_bitfield     Core register bit field macros
  \brief      Macros for use with bit field definitions (xxx_Pos, xxx_Msk).
  @{
 */

/**
  \brief   Mask and shift a bit field value for use in a register bit range.
  \param[in] field  Name of the register bit field.
  \param[in] value  Value of the bit field. This parameter is interpreted as an uint32_t type.
  \return           Masked and shifted value.
*/
#define _VAL2FLD(field, value)    (((uint32_t)(value) << field ## _Pos) & field ## _Msk)

/**
  \brief     Mask and shift a register value to extract a bit filed value.
  \param[in] field  Name of the register bit field.
  \param[in] value  Value of register. This parameter is interpreted as an uint32_t type.
  \return           Masked and shifted bit field value.
*/
#define _FLD2VAL(field, value)    (((uint32_t)(value) & field ## _Msk) >> field ## _Pos)

[andrewrk]

Note that translate-c does handle this, if the macros are used in C code. What is not handled is treating these macros as the API. What do you expect this example to translate to?

[frmdstryr]

Not sure why I used the code from math.h, I originally ran into this in core_cm7 where it is intended to be used as an API. I updated the example.

translate-c from #3973 makes these macros a compile error, but it doesn't seem like this is macro used elsewhere for the dev board I have so it's easy enough to manually translate these.

It's a low priority to have support for this so feel free to close.

[andrewrk]

Can you include a proposed output in the issue? What should it translate to?

[frmdstryr]

It'd be this I suppose:

pub inline fn _VAL2FLD(comptime field: var, comptime value: var) u32 {
    return ((@as(u32, value) << @field(@This(), field ++ "_Pos")) & @field(@This(), field ++ "_Msk");
}

You make a good point though. I guess it doesn't make sense to auto translate stuff like this to zig.

[andrewrk]

I didn't mean to imply that - I was asking sincerely. If there is a reasonable heuristic we can use to translate the macros into the expected output you have there, I'm happy with this to be a proposal. Generally, macros are translated as "best-effort". One cannot rely on macros being translated, but some of them will work.

[frmdstryr]

It might make sense to force the user to conceptually change thinking on stuff like this per-usecase basis though. I'm glad you asked because I didn't even think about it before.

Translating that macro made me realize that it expects everything to be available globally, which I didn't necessarily want. Now I'm wondering if it makes sense to auto translate at all or just do a from scratch port to a more zig like api...

[andrewrk]

Generally my advice would be to add C code which takes advantage of the macro, and creates inline functions to be translated into zig. That's the motivation behind #2070.