7

The following macro is from an MCAL source of a microcontroller and it converts timer ticks to milliseconds.

#define TICKS2MS(x)     ( (uint64) (((((uint64)(x)) * 1) + 0) / 100000) )

Could you please help me understand the significance of multiplying by 1 and adding 0?

m43dr3
  • 73
  • 3
  • 3
    This is a common definition used on many MCU's, where some of them needs a multiplier and an offset to complete conversion. – Frankie_C Jan 20 '22 at 12:54
  • 3
    The `+ 0` could indicate the possibility of rounding, but not implemented. For example `+ 50000` would round to the nearest unit. – Weather Vane Jan 20 '22 at 12:55
  • 8
    I suspect that this macro is created by simple code generator that is unable to remove unnecessary parts of expression even when parameters would allow to do so. – user694733 Jan 20 '22 at 12:56
  • 2
    Yes this is almost certainly auto-generated code. None who know what they are doing would write such nonsense manually. These integer constants are likely placeholders grabbed from some edit boxes in a GUI or whatever. – Lundin Jan 20 '22 at 14:05
  • 1
    This is probably because the second like contains `( (uint64) (((((uint64)(x)) * 2) + 1) / 100000) )` or something similar. And this is surely auto-generated code as shown by the weird spacing and then overall unreadability of the code. – Shambhav Jan 20 '22 at 16:02

2 Answers2

3

The multiplication and addition are in fact pointless, as is the outer cast.

Both operators perform the usual arithmetic conversions on both operands.

For the multiplication, the left operand has type uint64 (as a result of the cast) and the right operand has type int. Since uint64 is the larger type it will be the type of the result. The operand 1 does not change value as a result of the conversion, so in multiplying by 1 the result has the same type and value as (uint64)(x).

Similarly for the addition, the operands are of type uint64 and int respectively, meaning the resulting type is uint64, and 0 does not change value after the conversion. So by adding 0 the result has the same type and value as (uint64)(x) * 1 which has the same type and value as (uint64)(x).

The cast at the end is also superfluous, as the casted expression already has type uint64. As above, the division operator performs the usual arithmetic conversions on its operands so dividing a uint64 by an int results in a uint64.

So the above macro is equivalent to:

#define TICKS2MS(x)     ((uint64)(x) / 100000)
dbush
  • 205,898
  • 23
  • 218
  • 273
3

I see the words MCAL, TICKS2MS(x) and uint64 (not the uint64_t from stdint.h) .. and it sounds to me like this is an AUTOSAR Environment. (You should have added the autosartag to the question)

The different explicit casts are then most likely due to MISRA-C checks. The MISRA-C check tools can be quite nitpicking about this.

If that macro TICK2MS(x) is part of an xxx_Cfg.h or xxx_PBCfg.h (where xxx is like Gpt, Mcu or Os), then it is most likely generated by the AUTOSAR/MCAL Driver configuration tool. And then, the factor, offset and divider could be part of adjusting to prescaler and maybe a TimerMaxValue (wrap around) or a correction due to odd prescaler/frequency to ticks constellation, in order to correct the failure. If the config is such that such feature is not used, the default values might be generated by the configuration tool.

Since the macro contains only constants, the compiler can optimize this into a simple ((uint64)(x) / 100000).

kesselhaus
  • 1,241
  • 8
  • 9