HAL functions using archaic terms - why?

[onderdelen]

Hi,

I am compiling the STM32U0 HAL library and I get errors like this one:

/Users/kiwanda/techniek/swexternals/STM32/HAL/Libraries/STM32U0xx_HAL_Driver/Inc/stm32u0xx_ll_comp.h: In function 'uint32_t LL_COMP_GetCommonWindowMode(const COMP_Common_TypeDef*)':
/Users/kiwanda/techniek/swexternals/STM32/HAL/Libraries/STM32U0xx_HAL_Driver/Inc/stm32u0xx_ll_comp.h:391:27: error: ISO C++17 does not allow 'register' storage class specifier [-Werror=register]
  391 |   register const uint32_t window_mode_comp_odd = (uint32_t)READ_BIT(COMPxy_COMMON->CSR_ODD, COMP_CSR_WINMODE);

I am using a C++ compiler and since C++14 the keyword register has been declared obsolete and useless. I fully agree with this step, all the more since we are writing SW here on ARM Cortex:

When writing software for ARM Cortex, which is a Load/Store architecture RISC processor, EVERYTHING goes through a register. The register keyword is therefore completely meaningless, useless and superfluous in this context.

I would like to ask ST to write the HAL libraries in such a way that they can also be used in modern contexts like the one I prefer to use. Checking the library with a C++ compiler is very effective since it finds anomalies and errors that (lax) C compiler disregard.

with best regards,

Ewout Boks

Ewout Boks

[Andrew Neil]

---

@Ozone wrote:

 I cannot find such information regarding plain C.

---

It's not an issue for C; register is still a valid C keyword (though almost certainly ignored^*)

The OP is talking specifically about C++

As the thread title suggests, it is now an archaism - modern compilers are, indeed, far better at optimisation and will (largely) ignore this keyword.

The GCC documentation has this to say:

"In almost all cases, allowing the compiler to assign registers produces the best code"

but it does have some options for the very special cases where someone might have some genuine reason to do it:

Variables in Specified Registers

PS:

* Well, having qualified something as register, the rules for Register variables will be applied - such as not taking its address...

[Ozone]

> The OP is talking specifically about C++

The Cube source code is supposed to work in both C and C++ projects - at least this is what a cursory review of Cube sources suggest. Which means the author should have isolated lines and sections like this for either environment.
Or, since there are no requirement to support legacy hardware or toolchains, dropped such keywords in the first place.
My company uses git, which requires a code review by at least one more person and his approval for a pull request.

As a "funny" side note, I heard almost all of the modern "Z" series of IBM mainframes are specifically designed to emulate old IBM System/360 systems. A large majority of banks still continue to run software written for those systems in the '60s and '70s.
So much for "legacy" ...

[Andrew Neil]

---

@Ozone wrote:

The Cube source code is supposed to work in both C and C++ projects ...

---

Indeed - and this is an example where it fails to do that.

[Ozone]

Perhaps you heard about that "rule of three" that applies in software development.
These three determining factors are quality, speed of development, and cost.
Any emphasis on one will impact the others, either way.

With the speed of new ST silicon releases supported by Cube and the support packages being available for free, it is obvious what suffers ...

Just to point it out, this is not a ST-specific problem.

[onderdelen]

Thanks everyone for putting in their worthy knowledge!

Yes I know C still supports register. But HAL supposedly also supports C++ environments. The lines are not clearly drawn since C is a subset of C++ with a few exceptions such as this one. Based on what compilers docs such as Keil or gnu arm say, usage of the register keyword is not encouraged at all.

Over the years I have used in projects a number of the HAL libraries. After importing them locally, typical errors I get (compiling with a C++ compiler) :

• local variables shadowing global variables. Apparently C does not mind but C++ does not approve of this.
• comparing signed and unsigned variables in a boolean expression.
• the register keyword.
• variables that were declared but not used.

These were all minor thing and did not stop me from using the libraries with a C++ compiler. All in all my impression is that ST strives to get rid of annoying bugs like these and the quality of the HAL libraries has improved quite well over the years.

As a last note it can be said that the HAL library is already an object-oriented library, with all the XXX_HandleTypeDef structs holding the object parameters, Init() and DeInit() functions and such. Wrapping a class around it is not hard, so I hope this encourages ST to think more of the growing legion of C++ users like me or even publish a few classes themselves in the HAL library.

Ewout Boks