Re: Broken SH2a patches

[Joern RENNECKE <joern.rennecke@st.com>]

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.