On Fri, 2018-01-05 at 12:12 +0000, Sebastian Perta wrote: > > > > > > > Is this for some kind of legacy backwards compatibility of > > > something?
> Sort of, this is required by the following tool > https://www.renesas.com/en-eu/products/software-tools/tools/code- > generator/ap4-application-leading-tool-applilet.html > There are not many plans to improve this tool and other solutions > (which might be more complex) might not be possible to implement in > this tool. I see. > > The only way I can think of is to put the variable in a separate > section (using section attribute) and then in the linker script put > that section at the desired address. > The problem is AP4 does not touch the linker script it only generates > source code. > > Do you have any other ideas/suggestions? I'm very happy to listen. If you can compile the code only as plain C, for example #define const_addr_var(addr, type) (*(volatile type*)addr) #define DTCCR const_addr_var (0x00082400, uint8_t) #define DTCSTS const_addr_var (0x0008240E, uint16_t) If you can compile the code as C++11 there are certainly more options, albeit probably not useful for generated code. For example I do those things this way: // read-write hardware register with constant address static constexpr hw_reg_rw<uint8_t, const_addr<0x00082400>> DTCCR = { }; // ready-only hardware register with constant address static constexpr hw_reg_r<uint16_t, const_addr<0x0008240E>> DTCSTS = { }; In both cases (C and C++) the following will compile to the same code: void test_wr (void) { DTCCR = 123; } int test_rd (void) { return DTCSTS; } volatile void* get_reg_addr (void) { return &DTCCR; } For a possible implementation of the hw_reg thingy see https://github.com/shared-ptr/bits/blob/master/hw_reg.hpp But really, if that is just for some code generator, why not simply adjust the code generator to spit out normal C code instead of cluttering the compiler with non-portable pragmas? You have also posted a similar thing for RL78 a while ago, so in the end the same pragma thing would be re-implemented in the compiler three times (M32C, RL78, RX)? In that case, maybe better move it out from the M32C target and make it available for every target? Cheers, Oleg
