CODEWITHSUNDEEP
c++cgccmacros
sherrellbc
sherrellbc

Reputation: 4853

Do these macros evaluate to the same code using gcc at compile-time?

Of course this is going to be a function of the compiler you are using, but I figured this would be a simple question to answer. 

#define UBRRVAL(baud) (F_CPU/(16*baud)-1)

As compared with

#define UBRRVAL(baud) (F_CPU/16/baud-1)

I know that the latter is going to evaluate to (assuming F_CPU = 20000000):

#define UBRRVAL(baud) (12500000/baud-1)

Considering the forced precidence by the parenthesis I was curious to know if most compilers (gcc in particular) would evaluate the former expression equivalently to the latter at compile-time.

This is code that is going into an embeddded system, so if these expressions are not evaluated at compile-time equivalently, then the latter is more efficient; a single division at run-time is more efficient than a division and a mulitplication of course.

Upvotes: 2

Views: 158

Answers (2)

david.pfx
david.pfx

Reputation: 10868

Simple answer, yes. Within the specific constraints given both will be fully evaluated at compile time.

Parentheses force precedence but they do not force order of evaluation, except to the extent defined by the "as if" rule. You cannot be sure what code will be emitted if the expression is slightly more complicated so it is not evaluated at compile time. This may well depend on the specific processor.

As a side point, on most processors a 4 bit shift left or shift right are the same cost, and if the baud rate is a power of two the compiler is likely to generate shift operations.

[And be careful about parenthesising macro arguments. You got away with it this time, but only just.]

Upvotes: 1

twalberg
twalberg

Reputation: 62379

Simple answer, no.

Because neither macro is fully parenthesized, there are cases where the two are very different.

Consider UBRRVAL(2+1). The first would expand to (F_CPU/(16*2+1)-1), which is equivalent to F_CPU/33 - 1. The second would expand to (F_CPU/16/2+1-1), which is equivalent to F_CPU/32. Not the same at all.

Of course, it probably isn't meant to be called with an expression, just with a single constant value, but there's nothing to prevent it, and as such, someone will do it sometime in the future. One of the many evils of macros. I would recommend using a short (static) inline function (or constexpr as suggested in comments, if this is using a recent enough C++ compiler) instead...

Upvotes: 3

Related Questions