Re: Broken SH2a patches

[Ian Lance Taylor <ian@wasabisystems.com>]

Andrew STUBBS <andrew.stubbs@st.com> writes:

> 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.

To make this work, it sounds like you will need to change the ELF
header flags, and thus will lose some degree of backward
compatibility.  If you have to do that anyhow, why not change the ELF
flags to more appropriately reflect the situation?  Instead of trying
to represent all information with a single processor field, partition
the instruction set into groups, and use bitfields to indicate which
groups are represented in the object file.  It would probably be
appropriate to continue to have a processor field, to capture certain
large groups in a single number.  Then add a bit for, e.g., FPU
instructions.

I don't know how the SH architecture has evolved.  Would this sort of
approach be possible?

Ian