This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PING][RFC][PATCH] RL78 - Add predicates to reduce code bloat when accessing volatile memory.
- From: DJ Delorie <dj at redhat dot com>
- To: Richard Hulme <peper03 at yahoo dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 12 May 2014 16:12:24 -0400
- Subject: Re: [PING][RFC][PATCH] RL78 - Add predicates to reduce code bloat when accessing volatile memory.
- Authentication-results: sourceware.org; auth=none
- References: <535179B5 dot 6010607 at yahoo dot com> <536D259D dot 9080404 at yahoo dot com> <201405091920 dot s49JKtF4027627 at greed dot delorie dot com> <53712911 dot 1070709 at yahoo dot com>
> My understanding of 'volatile' is that even the resulting code I gave as
> an example is not actually volatile-safe:
>
> mov a, !240
> or a, #32
> mov !240, a
>
> as the value stored in address 240 could change just before and/or just
> after the 'or', and get overwritten by the second move.
That's not "volatile", that's "atomic". Volatile would mean, for
example, that if the C source showed one reference to the variable,
the assembler would have exactly one reference to the variable.
If, for example, you had an SImode integer, some patterns might read
the value more than once, which would violate the volatility. Those
patterns must not use the new predicates.
> As I understand it, one of the reasons for having the virtual pass was
> to make the instruction set appear completely orthogonal.
The reason is that the RL78 ISA is too unorthogonal for gcc to handle
at all. I tried, it didn't work.
> Why then, when every instruction can use every virtual register in
> any addressing mode, does it think that:
>
> movw r10, #240
> movw ax, r10
> movw hl, ax
> mov a, [hl]
> or a, #32
> mov [hl], a
>
> is more volatile-safe?
Again, volatile != atomic. As long as the assembler references the
variables exactly the same number of times as the C source says to,
it's volatile-safe.