embxx_on_rpi icon indicating copy to clipboard operation
embxx_on_rpi copied to clipboard

Many reinterpret_cast errors

Open gazzatav opened this issue 3 years ago • 2 comments

Running make after cmake gives hundreds of errors of the form:

error: reinterpret_cast from integer to pointer reinterpret_cast<volatile EntryType*>(0x20215068);

These are for the uart, the timer, the interruptManager etc.

Using gcc 11.1.0 on Ubuntu 18.04.

Is there a nicer way to do this anyway?

gazzatav avatar Oct 21 '22 22:10 gazzatav

Hi @gazzatav, Note that I haven't performed any development/maintenance for this project since gcc-4.8 times (approximately 2014). I don't have proper equipment (raspberry-pi) or time capacity to look after it. Please try to resolve the problems yourself and submit a pull-request if you feel like it.

Try to reinterpret_cast the numeric address value to void* first before reinterpret_cast-ing it the the volatile type. Maybe it will help.

arobenko avatar Oct 22 '22 03:10 arobenko

Hi @arobenko, yes, thanks for responding. I noticed that the project was not under active development for a while but thought it was worth commenting. In case anyone had a better way.

As it turns out, the C++ standard doesn't allow reinterpret_cast in a constexpr context (the constexpr context has changed since C++11 through C++14 and 17 to 20).

In another test program I tested simply removing constexpr from a similar statement and it seemed to work OK.

The following lines added to a small test program:

static volatile uint32_t *const pu = reinterpret_cast<volatile uint32_t*>(0x00000084);
uint32_t on = *pu;

compiled, linked and dumped with objdump on arm-none-eabi- produce these additional lines (in main):

877e:	2384      	movs	r3, #132	; 0x84
8780:	681b      	ldr	r3, [r3, #0]
8782:	64bb      	str	r3, [r7, #72]	; 0x48

I'm not sure if the third line of assembly is part of the above but it is a line that was not there before. To me it looks good but I'm not expert enough to know whether that is as efficient as it could be in terms of time and space.

I'll happily try to sort this out and make a pull request for this and the other problem I noticed #12 (but I might take a while).

gazzatav avatar Oct 22 '22 18:10 gazzatav