RE: [PATCH] RX pragma address

["Sebastian Perta" <sebastian dot perta at renesas dot com>]

Hello,

The AP4 tool team have agreed with this change and are willing to update their tool.
So I would like to drop this patch.

Best Regards,
Sebastian


-----Original Message-----
From: Sebastian Perta [mailto:sebastian.perta@renesas.com] 
Sent: 05 January 2018 13:46
To: 'Oleg Endo' <oleg.endo@t-online.de>; gcc-patches@gcc.gnu.org
Subject: RE: [PATCH] RX pragma address

Hi Oleg,

Thank you very much for those suggestions, they are definitely the better way to go.
>From my point of view I would like drop both patches(RX and RL78) however I contacted the AP4 tool team to see if they agree with this change and are willing to update their tool.
If not I will follow your suggestion and move it out from the M32C target and make it available for every target.

Best Regards,
Sebastian

-----Original Message-----
From: Oleg Endo [mailto:oleg.endo@t-online.de] 
Sent: 05 January 2018 12:50
To: Sebastian Perta <Sebastian.Perta@renesas.com>; gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] RX pragma address

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