RFA: Add support for Renesas RX architectiure to GCC

[Joseph S. Myers]

On Wed, 30 Sep 2009, Nick Clifton wrote:

> Hi Guys,
> 
>   On behalf of Red Hat I would like contribute support for a new
>   processor architecture to GCC.  This is for the Renesas RX cpu,
>   details of which can be found here:
> 
> http://eu.renesas.com/fmwk.jsp?cnt=rx600_series_landing.jsp&fp=/products/mpumcu/rx_family/rx600_series
> http://documentation.renesas.com/eng/products/mpumcu/rej09b0460_rx610hm.pdf

There should be a patch for readings.html to add the links there, and one 
for backends.html to describe the properties of this port.

> gcc/ChangeLog
> 
>         * config.gcc: Add rx-elf target.
>         * doc/extend.texi: Document RX function attributes and
> 	built-in functions.
>         * doc/invoke.texi: Document RX specific command line
> 	switches.

There should be an entry in contrib.texi for the contribution of this 
port.

See my checklist for new ports, "Back End" in sourcebuild.texi....

> +@item int __builtin_rx_bm<cnd> (int word, int bit)
> +Generates the @code{bm} machine instruction which sets or clears the
> +indicated bit in the indicated word based on the status of the
> +@code{<cnd>} condition.  Permited values for @code{<cnd>} are:
> +@samp{eq, ne, gt, ge, lt, le, gtu, geu, ltu, leu, pz, n, o, no}.

@var{cnd} (or @code{@var{cnd}}) instead of @code{<cnd>}.  Each value 
should go in its own @samp{} (@samp{eq}, @samp{ne}, ...).

> +@item void __builtin_rx_mvtc (int reg, int val)
> +Generates the @code{mvtc} machine instruction which sets control
> +register number @code{reg} to @code{val}.

As a general comment, if you wish to describe details of the semantics of 
arguments to built-in functions it would be best to use @deftypefn to 
format all the built-in functions.

@deftypefn {Built-in Function} void __builtin_rx_mvtc (int @var{reg}, int @var{val})

(and then use @var markup when naming the parameters in the description of 
the function).

> +@item int __builtin_rx_revw (int)
> +Generates the @code{revw} machine instruction which swaps the bytes in
> +the argument so that bits 0-7 now occupy bits 8-15 and vice versa, and
> +also bits 16-23 occupy bits 24-31 and vice versa.

Use an en dash ("--") in these ranges.

> +@item int __builtin_rx_sc<cnd> (void)
> +Generates the @code{sc} machine instruction to restrieve the specified
> +truth condition from the condition code flags.  Permited values for
> +@code{<cnd>} are: @samp{eq, ne, gt, ge, lt, le, gtu, geu, ltu, leu,
> +pz, n, o, no}.

Same comments as above about <cnd> and @samp formatting.

> +@item -mint-register=@var{N}
> +@opindex mint-register
> +Specify the number of registers to reserve for fast interrupt handler
> +functions.  The value @var{N} can be between 0 and 4.  A value of 1
> +means that register r13 will be reserved for ther exclusive use of
> +fast interrupt handlers.  A value of 2 reserves r13 and r12.  A value
> +of 3 reserves r13, r12 and r11, and a value of 4 reserves r13 through
> +r10.  A value of 0, the default, does not reserve any registers.
> +@end table
> +
> +@emph{Note:} The generic GCC command line @option{-ffixed-@var{reg}}
> +has special significance to the RX port when used with the
> +@code{interrupt} function attribute.  This attribute indicates a
> +function intended to process fast interrupts.  GCC will will ensure
> +that it only uses the registers @code{r10}, @code{r11}, @code{r12}
> +and/or @code{r13} and only provided that the normal use of the
> +corresponding registers have been restricted via the
> +@option{-ffixed-@var{reg}} or @option{-mint-register} command line
> +options.

Could you be consistent in how register numbers are formatted, i.e. use 
@code everywhere (my suggestion) or nowhere rather than sometimes using it 
and sometimes not using it?

There is a typo in predicates.md: "2008. 2009" should be "2008, 2009" in 
the copyright notice.

The diagnostic

>                   warning (0, "No fixed registers available for use by fast interrupt handler.");

should not start with a captial letter or end with a period.

-- 
Joseph S. Myers
joseph@codesourcery.com