This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
RE: Broken SH2a patches
- From: Andrew STUBBS <andrew dot stubbs at st dot com>
- To: "'Nick Clifton'" <nickc at redhat dot com>,"'Alexandre Oliva'" <aoliva at redhat dot com>
- Cc: <binutils at sources dot redhat dot com>
- Date: Fri, 29 Oct 2004 13:12:55 +0100
- Subject: RE: Broken SH2a patches
- Organization: STMicroelectronics
> > Nick, I take it that you didn't make any progress on them?
>
> That would be correct.
>
> Anyway as I understand it the problem is that the inheritance tree in
> sh-opc.h does not include the SH2A, right ? Judging from Alex's and
> Andrew's comments there are two possible fixes for this, a simple one
> that just adds the SH2A-nofpu and SH2A inheritance off the SH2E:
> --------------------------------------------------------------
> ---------
> /* Below are the 'architecture sets'.
> They describe the following inheritance graph:
>
> SH1
> |
> SH2
> .------------'|`--------------------.
> / | \
> SH-DSP SH3-nommu SH2E
> | |`--------. |`--------.
> | | \ | \
> | SH3 SH4-nommu-nofpu | |
> | | | | |
> | .------------'|`----------+---------. | |
> |/ / \| |
> | | .-------' | |
> | |/ | |
> SH3-dsp SH4-nofpu SH3E SH2A-nofpu
> | |`--------------------. | |
> | | \| |
> | SH4A-nofpu SH4 SH2A
> | .------------' `--------------------. |
> |/ \|
> SH4AL-dsp SH4A
> --------------------------------------------------------------
No. This is wrong. There is _no_way_ a no-fpu variant can descend from an
fpu variant - it would inherit the fpu!
> And a complex one that invents a fake intermediate
> architecture to show
> the fact that the SH4, SH4A and SH2A share some instructions. To my
> mind however there is no satisfactory way of showing this,
> and instead I
> would like to suggest using a dotted line to show partial inheritance:
> --------------------------------------------------------------
> -----------
> /* Below are the 'architecture sets'.
> They describe the following inheritance graph:
> (The .... between SH4A and SH2A-nofpu is a partial inheritance).
>
> SH1
> |
> SH2
> .------------'|`--------------------.
> / | \
> SH-DSP SH3-nommu SH2E
> | |`--------. |`------.
> | | \ | \
> | SH3 SH4-nommu-nofpu | |
> | | | | |
> | .------------'|`----------+---------. | |
> |/ / \| |
> | | .-------' | |
> | |/ | |
> SH3-dsp SH4-nofpu SH3E |
> | |`--------------------. | |
> | | \| |
> | SH4A-nofpu SH4 |
> | .------------' `--------------------. | |
> |/ \| |
> SH4AL-dsp SH4A |
> . |
> ......... |
> . |
> SH2A-no-fpu
> |
> SH2A
> --------------------------------------------------------------
I agree that there may be some problem inserting it into the diagram, but
the important ting is that it must be inserted into the inheritance tree in
the code and that the |s (ors) are removed from the instruction table (the
op32 stuff may be ok, but the others have to go).
Each and every instruction has to be introduced in one single architecture
(albeit imaginary) and then be inherited by each and every one of its
descendents. If this condition is not met then the algorithms in cpu-sh.c
won't work and you find yourself forced to use the --isa option to sort out
the mess.
With the |s in place as they are the assembler _may_ work ok, but when it
comes to save the file it has to translate that into an elf flag. When there
are actually two architectures chosen (using | in the opcode table) then it
can only choose one and the other information is lost. Therefore, when the
file is loaded, the linker will not believe that it can link it against half
the architectures it actually could link against. This is why you are forced
to tell it which half manually using the -isa option.
So lets consider the rules as I understand them (I haven't examined the
opcodes table too carefully - this is just a thought experiment):
- The sh2a_nofpu contains everything in sh2, some things from sh3_nommu, and
some things of its own:
SH2
|
SH2A-nofpu-1
| \
SH3-nommu SH2A-nofpu
- The sh2a contains everything from sh2a_nofpu, some things from sh3e, some
things from sh4 and some things of its own:
SH2A-nofpu
| `--.
SH2A-1 SH2A-2
| \ / |
SH3E SH2A |
| |
`----. .----'
SH4
I have omitted the SH3-* and SH4-* intermediates but you get the idea (you
will need to consider if there any clashes with those as well). The
SH2A-*-[12] variants contain those instructions which are present in both
descendents - i.e. they are the common ancestor to which those instructions
can be traced.
I do not claim that the rules above are actually correct - I have gleaned
them from memory of emails rather than solid facts - nor am I suggesting
that the intermediate names are suitable. These are intended as a tutorial
only.
My other concern is the arch_op32 thingy. I don't know what it is for, or
what the affect on the architecture code is, but you should be aware that it
will not be encoded into the elf flags and, therefore, will not be available
at link time. If it is only intended to be for the assembler then it may be
ok.
Once this is done you should create a small assembler file for each
architecture the assembler and linker can produce (fake or real - they will
all need elf codes assigned) and put it in the 'arch' testsuite directory
(there is one under both the assembler and linker). If the architecture
permutation test script produces the correct result then you know you have
done the job right (but it will take some manual effort to verify the
results first time).
I hope that helps. I have tried to make sense but it isn't easy.
It would be much easier if we forced the people who invented the SH family
to maintain this themselves - sort of like house training. It does
demonstrate why the old merge macro was doomed to failure.
Good luck
--
Andrew Stubbs
andrew.stubbs@st.com
andrew.stubbs@superh.com