public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Andrew STUBBS <andrew.stubbs@st.com>
To: "'Nick Clifton'" <nickc@redhat.com>
Cc: "'Alexandre Oliva'" <aoliva@redhat.com>,
	<binutils@sources.redhat.com>,
	"'Joern RENNECKE'" <joern.rennecke@st.com>
Subject: RE: Broken SH2a patches
Date: Thu, 16 Dec 2004 13:24:00 -0000	[thread overview]
Message-ID: <01bf01c4e372$a1525180$0d0f81a4@uk.w2k.superh.com> (raw)
In-Reply-To: <41C06DE2.1070806@redhat.com>

Hi Nick,

>    Features of this patch include:
> 
>      * I did not try to update the ASCII art in sh-opc.h with the new 
> relationships.  In my opinion it just makes the diagram too 
> cluttered to 
> be useful anymore.

Hmmm. That may be true, but I don't like it.

Here's my bash at it (note that the inheritance isn't quite as you had it -
see below):

                SH1
                 |
                SH2
   .------------'|`--------------------------------.
  /              |                                  \
SH-DSP          SH3-nommu/SH2A-nofpu               SH2E
 |               |          |`--------------------. |
 |               |          |                      \|
 |              SH3-nommu  SH4-nm-nf/SH2A-nofpu    SH3E/SH2A
 |               |\         |          |            |     |
 |               | `------. |        SH2A-nofpu     |     |
 |               |         \|            \          |     |
 |              SH3     SH4-nommu-nofpu   `---------+---. |
 |              /|\         |                       |    \|
 | .-----------' | `--------+---------------------. |    SH4/SH2A
 |/              |          /                      \|     |
 |               | .-------'                        |     |
 |               |/                                 |     |
SH3-dsp         SH4-nofpu                          SH3E  /|
 |               |`-------------------------------. | .-' |
 |               |                                 \|/    |
 |              SH4A-nofpu                         SH4   SH2A
 | .------------' `-------------------------------. |
 |/                                                \|
SH4AL-dsp                                          SH4A

Probably there ought to be a comment associated with the diagram explaining
that SHx/SHy refers to the intersection between the two architecures.
Alternatively the intersections could be made less confusing/dominant by
replacing their names with letters and then adding a legend (perhaps also
with details of shifts and prefetch differences).

>      * I have tried to use more meaningful names for the new 
> machine values.
> 
>     * I have added tests for the new machine values to the SH 
> specific 
> parts of the GAS and LD testsuites.
> 
> What do you think ?

These are all good things, and now there is a problem highlighted in the
test results:

One example:
+ sh2a-nofpu-or-sh3-nommu.s -isa=sh2e                 sh2a-or-sh3e

When -isa=sh2e it shouldn't be able to output any other isa, but it clearly
is. This is repeated many times. I think this is down to the fact that you
haven't created any new base architectures, but instead ored them together:

! #define arch_sh2a_or_sh3e                  (arch_sh2a_base|arch_sh3_base)

I haven't proven this though.

In addition to this, the inheritance tree still isn't quite right. I'm
beginning to think that if the head maintainer can't get this right then it
must be too complicated. I can't think of a better way though. Whatever
technique we use it needs to be able to select an architecture, based on the
instructions in the file, that specifies what architecture the file will run
on, without excluding any other similar, but different, architectures that
it may also run on (hence the fake architectures). Any ideas?

Specifically the problem is here

#define arch_sh3e_up       (arch_sh3e            | arch_sh2a_or_sh4_up)

and here

#define arch_sh3_nommu_up  (arch_sh3_nommu       \
		| arch_sh3_up | arch_sh2a_nofpu_or_sh4_nommu_nofpu_up)

Both these inheritances cause SH2A to allow SH3 instructions. E.g. 'ldc Rn,
SSR', 'ldc Rn, Rn_BANK' etc.  According to the document I have from the
Renesas web site the SH2A does not have such instructions. Joern and I
therefore think that the SH2A may descend from nothing but the SH2 and SH2e,
and instead it conceptually introduces some of the instructions used by the
SH3 and SH4. The diagram above shows this, but we have not checked this
instruction-by-instruction.

The code would then read:

/* Central branches.  */
#define arch_sh1_up                            (arch_sh1 \
		| arch_sh2_up)
#define arch_sh2_up                            (arch_sh2 \
		| arch_sh2e_up \
		| arch_sh2a_nofpu_or_sh3_nommu_up \
		| arch_sh_dsp_up)
#define arch_sh2a_nofpu_or_sh3_nommu_up        (arch_sh2a_nofpu_or_sh3_nommu
\
		| arch_sh2a_nofpu_or_sh4_nommu_nofpu_up \
		| arch_sh2a_or_sh3e_up \
		| arch_sh3_nommu_up)
#define arch_sh2a_nofpu_or_sh4_nommu_nofpu_up
(arch_sh2a_nofpu_or_sh4_nommu_nofpu \
		| arch_sh2a_nofpu_up \
		| arch_sh4_nommu_nofpu_up)
#define arch_sh2a_nofpu_up                     (arch_sh2a_nofpu \
		| arch_sh2a_or_sh4_up)
#define arch_sh3_nommu_up                      (arch_sh3_nommu \
		| arch_sh3_up \
		| arch_sh4_nommu_nofpu_up)
#define arch_sh3_up                            (arch_sh3 \
		| arch_sh3e_up \
		| arch_sh3_dsp_up \
		| arch_sh4_nofp_up)
#define arch_sh4_nommu_nofpu_up                (arch_sh4_nommu_nofpu \
		| arch_sh4_nofp_up)
#define arch_sh4_nofp_up                       (arch_sh4_nofpu \
		| arch_sh4_up \
		| arch_sh4a_nofp_up)
#define arch_sh4a_nofp_up                      (arch_sh4a_nofpu \
		| arch_sh4a_up \
		| arch_sh4al_dsp_up)

/* Right branches.  */
#define arch_sh2e_up                           (arch_sh2e \
		| arch_sh2a_or_sh3e_up)
#define arch_sh2a_or_sh3e_up                   (arch_sh2a_or_sh3e \
		| arch_sh2a_or_sh4_up \
		| arch_sh3e_up)
#define arch_sh2a_or_sh4_up                    (arch_sh2a_or_sh4 \
		| arch_sh2a_up \
		| arch_sh4_up)
#define arch_sh2a_up                           (arch_sh2a)
#define arch_sh3e_up                           (arch_sh3e \
		| arch_sh4_up)
#define arch_sh4_up                            (arch_sh4 \
		| arch_sh4a_up)
#define arch_sh4a_up                           (arch_sh4a)

/* Left branch.  */
#define arch_sh_dsp_up                         (arch_sh_dsp  \
		| arch_sh3_dsp_up)
#define arch_sh3_dsp_up                        (arch_sh3_dsp \
		| arch_sh4al_dsp_up)
#define arch_sh4al_dsp_up                      (arch_sh4al_dsp)

Please check this over yourself, but it looks right to me. I'm pretty sure
it matches the diagram above, but I'm not certain that both match the SH2A
architecture. There's plenty of room for screw ups here.

We're thinking about ways to automate/simplify this stuff, but nothings
going to happen this year I wouldn't think.

-- 
Andrew Stubbs
andrew.stubbs@st.com
(aka. andrew.stubbs@superh.com)

  reply	other threads:[~2004-12-16 13:24 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-13 17:00 Andrew STUBBS
2004-10-28 20:33 ` Alexandre Oliva
2004-10-29 10:39   ` Nick Clifton
2004-10-29 12:11     ` Andrew STUBBS
2004-10-29 12:28       ` [OT] " Dave Korn
2004-10-29 12:59         ` Andrew STUBBS
2004-10-29 13:03           ` Dave Korn
2004-10-29 13:21             ` Andrew STUBBS
2004-10-29 13:59       ` Ian Lance Taylor
2004-10-29 14:35         ` Andrew STUBBS
2004-10-29 14:58           ` Ian Lance Taylor
2004-10-29 15:44             ` Andrew STUBBS
2004-11-08  9:04       ` Nick Clifton
2004-11-08 15:12         ` Andrew STUBBS
2004-11-08 16:27           ` Joern RENNECKE
2004-11-08 16:36           ` Joern RENNECKE
2004-12-15 17:11           ` Nick Clifton
2004-12-16 13:24             ` Andrew STUBBS [this message]
2004-12-20 17:18               ` Nick Clifton
2005-01-05 13:27                 ` Andrew STUBBS
2005-01-06 11:28                 ` Andrew STUBBS
2005-01-12 16:23                   ` Nick Clifton
2005-01-07 12:55                 ` Andrew STUBBS
2005-01-10 13:31                   ` Joern RENNECKE
2005-01-11 18:01                 ` Andrew STUBBS
2004-12-02 12:19 Andrew STUBBS

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='01bf01c4e372$a1525180$0d0f81a4@uk.w2k.superh.com' \
    --to=andrew.stubbs@st.com \
    --cc=aoliva@redhat.com \
    --cc=binutils@sources.redhat.com \
    --cc=joern.rennecke@st.com \
    --cc=nickc@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).