Housekeeping work in backends.html

Hi,

the attached patch removes obsolete ports (c4x, m68hc11 and ms1), toggles the 
'p' letter and adjust accordingly (only avr, fr30, m68k, mcore, rs6000 and sh 
still use define_peephole) and removes trailing spaces.

OK to commit?

Some ports are missing (lm32, moxie, nios2, nvptx, rl78, rx) so the relevant 
maintainers are CCed (see 6.3.9 Anatomy of a Target Back End in the doc).

On 01/05/15 16:15, Eric Botcazou wrote:
> Hi,
>
> the attached patch removes obsolete ports (c4x, m68hc11 and ms1), toggles the
> 'p' letter and adjust accordingly (only avr, fr30, m68k, mcore, rs6000 and sh
> still use define_peephole) and removes trailing spaces.
>
> OK to commit?
>
> Some ports are missing (lm32, moxie, nios2, nvptx, rl78, rx) so the relevant
> maintainers are CCed (see 6.3.9 Anatomy of a Target Back End in the doc).
This is fine.

I might claim updating this shouldn't ever require a review :-)

jeff

On 01/05/2015 04:15 PM, Eric Botcazou wrote:
> Hi,
>
> the attached patch removes obsolete ports (c4x, m68hc11 and ms1), toggles the
> 'p' letter and adjust accordingly (only avr, fr30, m68k, mcore, rs6000 and sh
> still use define_peephole) and removes trailing spaces.
>
> OK to commit?
>
> Some ports are missing (lm32, moxie, nios2, nvptx, rl78, rx) so the relevant
> maintainers are CCed (see 6.3.9 Anatomy of a Target Back End in the doc).

I think that for nios2 the correct entry is probably "SCpd", but the 
descriptions of some of the things in the table are too terse for me to 
be 100% sure that's correct.  E.g., the nios2 architecture doesn't 
include the concept of "condition codes" at all, so how many registers 
they might occupy seems irrelevant.  And, I think the "S" (no free 
simulator) situation will probably be resolved soon, and it's hardly a 
property of either the architecture or the GCC port....

-Sandra

> Some ports are missing (lm32, moxie, nios2, nvptx, rl78, rx) so the relevant
> maintainers are CCed (see 6.3.9 Anatomy of a Target Back End in the doc).

The page is directly browsable at https://gcc.gnu.org/backends.html

For the moxie, nvptx, rl178 and rx ports, maintainers can send me the string 
as Sandra did for the nios2 port and I'll update the document.

Hi Eric,

On Wed, Jan 7, 2015 at 2:39 AM, Eric Botcazou <ebotcazou@adacore.com> wrote:
> The page is directly browsable at https://gcc.gnu.org/backends.html
>
> For the moxie, nvptx, rl178 and rx ports, maintainers can send me the string
> as Sandra did for the nios2 port and I'll update the document.

Xtensa is now supported by the QEMU, so probably question mark in its 'S' slot
may be removed.

> Xtensa is now supported by the QEMU, so probably question mark in its 'S'
> slot may be removed.

Done, thanks.

On 01/07/2015 12:39 AM, Eric Botcazou wrote:
>> Some ports are missing (lm32, moxie, nios2, nvptx, rl78, rx) so the relevant
>> maintainers are CCed (see 6.3.9 Anatomy of a Target Back End in the doc).
>
> The page is directly browsable at https://gcc.gnu.org/backends.html
>
> For the moxie, nvptx, rl178 and rx ports, maintainers can send me the string
> as Sandra did for the nios2 port and I'll update the document.

For nvptx it's not really clear what to use in some cases, and in others 
I have no idea why we would need to keep track of these "characteristics".

H - you could argue a hardware implementation does not exist as it's a
     virtual target, but it can obviously be compiled down to run on
     hardware that does exist.
Q - "registers" are typed and you can declare 64 bit registers, so
     probably this is true
f - Not even sure what this is about. It only defines a small epilogue
     pattern.
a - Port uses neither LRA nor reload. Might be a new characteristic
     (along with several others).

The closest string is probably

SQCqfbde


Bernd

> H - you could argue a hardware implementation does not exist as it's a
>      virtual target, but it can obviously be compiled down to run on
>      hardware that does exist.

Agreed.

> Q - "registers" are typed and you can declare 64 bit registers, so
>      probably this is true

OK.

> f - Not even sure what this is about. It only defines a small epilogue
>      pattern.

I think this means that the port still uses asm prologue/epilogue.  That's not 
the case here, so 'f' should probably be omitted and 'g' be added.

As a matter of fact, there are no ports left with 'f'.

> a - Port uses neither LRA nor reload. Might be a new characteristic
>      (along with several others).
> 
> The closest string is probably
> 
> SQCqfbde

Thanks, I have installed "SQCqgbde" based on the discussion above.

Eric Botcazou <ebotcazou@adacore.com> writes:

> Some ports are missing (lm32, moxie, nios2, nvptx, rl78, rx) so the relevant 
> maintainers are CCed (see 6.3.9 Anatomy of a Target Back End in the doc).

I think I got this right....

           |      Characteristics
Target     | HMSLQNFICBD lqrcpfgmbdiates
-----------+----------------------------
moxie      |       F           g  d    s


AG

> I think I got this right....
> 
>            |      Characteristics
> 
> Target     | HMSLQNFICBD lqrcpfgmbdiates
> -----------+----------------------------
> moxie      |       F           g  d    s

Thanks, applied, but I think that 't' could be added because AFAICS every insn 
(not expander) generates exactly 1 assembly instruction.  Not very important 
though since only iq2000 and mep also have this nice property.