Re: SH5 simulator contribution

[Andrew Cagney <ac131313@cygnus.com>]

> So I don't see that you gain anything by unifying the numbering scheme
>> > in the gdb <-> sim interface, as it would be at odds with the interface
>> > to gcc and the hardware interfaces.
> 
>> 
>> Formalizing would be a better word.  So that GDB and the SIM can agree
>> on the register numbers and their sizes without needing to know the
>> others internals.
> 
> 
> They only need to know if the program is for an sh5 or an earlier processor.
> This information is readily available from the elf flags (the lower five bits
> of which enconde the sh version this program is compiled for), or the bfd
> word size.  Gdb already needs to know this in order to print registers in the
> correct size, and the simulator in order to simulate the right instruction
> set(s).

Yes?

> So do you want a file that explicitly documents the two interface?
> The danger of this is that if registers are added to a successor of the sh5,
> the documentation can get out-of-sync with the header file.

Sorry, you've lost me here.  There should be only one GDB:SIM interface 
for the SH.

> Or should we rather make an include/sim-sh.h file - to be used in the old
> simulators sim_fetch_register / sim_store_register as well as in the
> to-be-written translation function in the new simulator for sh2-sh4 programs,
> and state in gdbint.texi that the interfaces are defined in include/sim-sh.h
> and include/sim-sh64.h ?

Having just looked at a different target (similar problem), I think 
having a single file that assigns different number ranges to the sh4 vs 
sh64 registers would be best.  That would make it easy to detect things 
like trying to fetch an SH64 register from the SH4 sim.

Andrew