Broken SH2a patches
Joern RENNECKE
joern.rennecke@st.com
Mon Jan 10 13:31:00 GMT 2005
Andrew STUBBS wrote:
> Ideally, if there was an extra section involved, we would also
>store information about the ABI used in the file, as mixing these is more
>serious than mixing architectures.
>
While mixing compatible architectures is fine, mixing processors from
the sh2e branch
with ones from the sh-dsp branch of the family is an absoilute no-no.
Unless someone
comes up with a mode-switched processor that can run both instruction
sets ;-) .
On the other hand, mixing code with different ABIs in one executable can
make perfect
sense, if you have some single-fp heavy code and some double-fp heavy
code. You
just to make sure that you use proper symbol wrapping for __fpscr_values
and use
appropriate glue for calling between different ABIs. In fact, we could
make gcc do
the interlinking automatically with machine specific attributes, if that
seems worthwhile.
> An alternative approach would be to list all the architectures it
> cannot run
> on. This would have the effect that old programs would be concidered
> to run
>
>on new architectures, even if they are unsuitable. Perhaps something more
>intellegent could be done if both sets were known.
>
Something that will allow a bit more upward compatibility is to list all
architectures
the code can run on that are not a proper superset of any other listed one.
This would be equivalent in terms of described sets and future upward
compatibility to
the current scheme (the fake nodes stand for intersections of
instruction sets of
actual processors, just as the architecture lists do).
>We would also have to consider the -isa option. Currently it allows
>individual architectures, which need not change, but also a -up for each,
>which might no longer make sense. Also, the -isa option is significant
>because it allows the assembler to use architecture specific relaxation
>optimisations (which it could not do if it were not certain of the
>architcture).
>
More exactly, the assembler encodes this information in the object file
so that the
linker can then do these relaxations. The linker both needs to know
about what
instructions are available - e.g. braf is only available from SH2
upwards - as well
as about what relaxations make sense at all - e.g. the instruction
reordering done
for SH2 memory access scheduling hurts SH4, and the algorith can also
confuse
integer and floating point registers.
More information about the Binutils
mailing list