sh64 simulator register numbers

sh64 simulator register numbers

[Joern Rennecke]

[-- Attachment #1: Type: text/plain, Size: 449 bytes --]

AFAICS the sh64 simulator doesn't need any changes for this renumbering,
while gdb would need some decoupling from the simulator's register numbers.

Should we create a header file that describes the register numbers when
talking to hardware, and make gdb use that for its internal numbers?
Or should it define the numbers inside sh-tdep.c ?

-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

[-- Attachment #2: sh64-sim-regnos --]
[-- Type: text/plain, Size: 3281 bytes --]

Index: sim-sh.h
===================================================================
RCS file: /cvs/src/src/include/gdb/sim-sh.h,v
retrieving revision 1.2
diff -p -r1.2 sim-sh.h
*** sim-sh.h	17 Jul 2002 18:43:26 -0000	1.2
--- sim-sh.h	17 Jul 2002 19:26:54 -0000
*************** enum
*** 131,154 ****
    SIM_SH_R6_BANK_REGNUM,
    SIM_SH_R7_BANK_REGNUM
    /* 100..127: room for expansion.  */
- };
  
! enum
! {
!   SIM_SH64_R0_REGNUM = 0,
!   SIM_SH64_SP_REGNUM = 15,
!   SIM_SH64_PC_REGNUM = 64,
!   SIM_SH64_SR_REGNUM = 65,
!   SIM_SH64_SSR_REGNUM = 66,
!   SIM_SH64_SPC_REGNUM = 67,
!   SIM_SH64_TR0_REGNUM = 68,
!   SIM_SH64_FPCSR_REGNUM = 76,
!   SIM_SH64_FR0_REGNUM = 77
  };
  
  enum
  {
!   SIM_SH64_NR_REGS = 141,  /* total number of architectural registers */
    SIM_SH64_NR_R_REGS = 64, /* number of general registers */
    SIM_SH64_NR_TR_REGS = 8, /* number of target registers */
    SIM_SH64_NR_FP_REGS = 64 /* number of floating point registers */
--- 131,174 ----
    SIM_SH_R6_BANK_REGNUM,
    SIM_SH_R7_BANK_REGNUM
    /* 100..127: room for expansion.  */
  
!   /* SHmedia */
!   SIM_SH64_R0_REGNUM = 128,
!   SIM_SH64_SP_REGNUM   = SIM_SH64_R0_REGNUM+15,
!   SIM_SH64_PC_REGNUM   = SIM_SH64_R0_REGNUM+64,
!   /* 64 64-bit control registers */
!   SIM_SH64_CR0_REGNUM  = SIM_SH64_R0_REGNUM+65,
!   /* Some of these have specific names.  */
!   SIM_SH64_SR_REGNUM   = SIM_SH64_CR0_REGNUM,    /* Status reg            */
!   SIM_SH64_SSR_REGNUM  = SIM_SH64_CR0_REGNUM+1,  /* Saved status reg      */
!   SIM_SH64_PSSR_REGNUM = SIM_SH64_CR0_REGNUM+2,  /* Panic-saved status reg*/
!   SIM_SH64_INTEVT_REGNUM=SIM_SH64_CR0_REGNUM+4,  /* Interrupt event reg   */
!   SIM_SH64_EXPEVT_REGNUM=SIM_SH64_CR0_REGNUM+5,  /* Exception event reg   */
!   SIM_SH64_PEXPEVT_REGNUM= SIM_SH64_CR0_REGNUM+6,/* Panic-saved Exception
! 								event reg */
!   SIM_SH64_TRA_REGNUM  = SIM_SH64_CR0_REGNUM+7,  /* TRAP exception reg    */
!   SIM_SH64_SPC_REGNUM  = SIM_SH64_CR0_REGNUM+8,  /* Saved program counter */
!   SIM_SH64_PSPC_REGNUM = SIM_SH64_CR0_REGNUM+9,  /* Panic-saved program
! 								  counter */
!   SIM_SH64_RESVEC_REGNUM=SIM_SH64_CR0_REGNUM+10, /* Reset vector          */
!   SIM_SH64_VBR_REGNUM  = SIM_SH64_CR0_REGNUM+11, /* Vector base register  */
!   SIM_SH64_TEA_REGNUM  = SIM_SH64_CR0_REGNUM+13, /* Faulting effective
! 							 address register */
!   SIM_SH64_DCR_REGNUM  = SIM_SH64_CR0_REGNUM+16, /* Debug control reg     */
!   SIM_SH64_KCR0_REGNUM = SIM_SH64_CR0_REGNUM+17, /* Kernel register 0     */
!   SIM_SH64_KCR1_REGNUM = SIM_SH64_CR0_REGNUM+18, /* Kernel register 1     */
!   SIM_SH64_CTC_REGNUM  = SIM_SH64_CR0_REGNUM+62, /* Clock tick counter    */
!   SIM_SH64_USR_REGNUM  = SIM_SH64_CR0_REGNUM+63, /* User-accessible
! 							  status register */
!   SIM_SH64_CR63_REGNUM = SIM_SH64_R0_REGNUM+128,
!   SIM_SH64_TR0_REGNUM  = SIM_SH64_R0_REGNUM+129,
!   SIM_SH64_FPSCR_REGNUM= SIM_SH64_R0_REGNUM+137,
!   SIM_SH64_FR0_REGNUM  = SIM_SH64_R0_REGNUM+138
  };
  
  enum
  {
!   SIM_SH64_NR_REGS = 202,  /* total number of architectural registers */
    SIM_SH64_NR_R_REGS = 64, /* number of general registers */
    SIM_SH64_NR_TR_REGS = 8, /* number of target registers */
    SIM_SH64_NR_FP_REGS = 64 /* number of floating point registers */

Re: sh64 simulator register numbers

[Andrew Cagney]

> AFAICS the sh64 simulator doesn't need any changes for this renumbering,
> while gdb would need some decoupling from the simulator's register numbers.
> 
> Should we create a header file that describes the register numbers when
> talking to hardware, and make gdb use that for its internal numbers?
> Or should it define the numbers inside sh-tdep.c ?

See the directory gdb/regformats/ and (more importantly) the mail 
archives for information on the changes that are being made to GDB so 
that it will eventually be able to handle remote register numbers.

--

Anyway, the below is wrong.  As was pointed out before, the enum values 
should not be hardwired.

Andrew

> !   /* SHmedia */
> !   SIM_SH64_R0_REGNUM = 128,
> !   SIM_SH64_SP_REGNUM   = SIM_SH64_R0_REGNUM+15,
> !   SIM_SH64_PC_REGNUM   = SIM_SH64_R0_REGNUM+64,
> !   /* 64 64-bit control registers */
> !   SIM_SH64_CR0_REGNUM  = SIM_SH64_R0_REGNUM+65,
> !   /* Some of these have specific names.  */
> !   SIM_SH64_SR_REGNUM   = SIM_SH64_CR0_REGNUM,    /* Status reg            */
> !   SIM_SH64_SSR_REGNUM  = SIM_SH64_CR0_REGNUM+1,  /* Saved status reg      */
> !   SIM_SH64_PSSR_REGNUM = SIM_SH64_CR0_REGNUM+2,  /* Panic-saved status reg*/
> !   SIM_SH64_INTEVT_REGNUM=SIM_SH64_CR0_REGNUM+4,  /* Interrupt event reg   */
> !   SIM_SH64_EXPEVT_REGNUM=SIM_SH64_CR0_REGNUM+5,  /* Exception event reg   */
> !   SIM_SH64_PEXPEVT_REGNUM= SIM_SH64_CR0_REGNUM+6,/* Panic-saved Exception
> ! 								event reg */
> !   SIM_SH64_TRA_REGNUM  = SIM_SH64_CR0_REGNUM+7,  /* TRAP exception reg    */
> !   SIM_SH64_SPC_REGNUM  = SIM_SH64_CR0_REGNUM+8,  /* Saved program counter */
> !   SIM_SH64_PSPC_REGNUM = SIM_SH64_CR0_REGNUM+9,  /* Panic-saved program
> ! 								  counter */
> !   SIM_SH64_RESVEC_REGNUM=SIM_SH64_CR0_REGNUM+10, /* Reset vector          */
> !   SIM_SH64_VBR_REGNUM  = SIM_SH64_CR0_REGNUM+11, /* Vector base register  */
> !   SIM_SH64_TEA_REGNUM  = SIM_SH64_CR0_REGNUM+13, /* Faulting effective
> ! 							 address register */
> !   SIM_SH64_DCR_REGNUM  = SIM_SH64_CR0_REGNUM+16, /* Debug control reg     */
> !   SIM_SH64_KCR0_REGNUM = SIM_SH64_CR0_REGNUM+17, /* Kernel register 0     */
> !   SIM_SH64_KCR1_REGNUM = SIM_SH64_CR0_REGNUM+18, /* Kernel register 1     */
> !   SIM_SH64_CTC_REGNUM  = SIM_SH64_CR0_REGNUM+62, /* Clock tick counter    */
> !   SIM_SH64_USR_REGNUM  = SIM_SH64_CR0_REGNUM+63, /* User-accessible
> ! 							  status register */
> !   SIM_SH64_CR63_REGNUM = SIM_SH64_R0_REGNUM+128,
> !   SIM_SH64_TR0_REGNUM  = SIM_SH64_R0_REGNUM+129,
> !   SIM_SH64_FPSCR_REGNUM= SIM_SH64_R0_REGNUM+137,
> !   SIM_SH64_FR0_REGNUM  = SIM_SH64_R0_REGNUM+138

Re: sh64 simulator register numbers

[Joern Rennecke]

Andrew Cagney wrote:
> See the directory gdb/regformats/ and (more importantly) the mail
> archives for information on the changes that are being made to GDB so
> that it will eventually be able to handle remote register numbers.

Hmm. Interesting.  But the documentation seems to be mostly in the 
'looking for volunteers' stage.

Can you give some salient time frames and/or keywords to narrow down the
search space a bit?

Has this been treated both in gdb and gdb-patches?

> Anyway, the below is wrong.  As was pointed out before, the enum values
> should not be hardwired.

Hmm, I didn't realize you want to change the sh64 simulator interface
every time a register is added to the sh4 interface.
Still, as this is linked into a single executable, I suppose this
is managable.
> > !   /* SHmedia */
> > !   SIM_SH64_R0_REGNUM = 128,

So you want this assignment to 128 be dropped, so that SIM_SH64_R0_REGNUM
just gets the next free number?

The rest is all relative to SIM_SH64_R0_REGNUM.
There are 64 general purpose registers, starting with R0.  The stack
pointer is R15. 
> > !   SIM_SH64_SP_REGNUM   = SIM_SH64_R0_REGNUM+15,

After the general purpose registers, we want the program counter.
Is this assignment OK with you?
> > !   SIM_SH64_PC_REGNUM   = SIM_SH64_R0_REGNUM+64,

Or do you want r63 to be assigned a number relative to r0, and then
get automatically the next number for pc?

Or should we enumerate all 64 of the general purpose registers?

Similar considerations apply to the 64 control registers,
8 target registers, how to assign a number to fpscr, and
the 64 floating point registers.
	
-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

Re: sh64 simulator register numbers

[Andrew Cagney]

> Andrew Cagney wrote:
> 
>> See the directory gdb/regformats/ and (more importantly) the mail
>> archives for information on the changes that are being made to GDB so
>> that it will eventually be able to handle remote register numbers.
> 
> 
> Hmm. Interesting.  But the documentation seems to be mostly in the 
> 'looking for volunteers' stage.
> 
> Can you give some salient time frames and/or keywords to narrow down the
> search space a bit?

Some words would include regcache remote.c (especially all recent patches).

>> > !   /* SHmedia */
>> > !   SIM_SH64_R0_REGNUM = 128,
> 
> 
> So you want this assignment to 128 be dropped, so that SIM_SH64_R0_REGNUM
> just gets the next free number?

Yes, a pure enum.  As mentioned before, the d10v et.al. all do this.

> The rest is all relative to SIM_SH64_R0_REGNUM.
> There are 64 general purpose registers, starting with R0.  The stack
> pointer is R15. 
> 
>> > !   SIM_SH64_SP_REGNUM   = SIM_SH64_R0_REGNUM+15,

If a register has an alternative name, define that in a separate enum vis:

	enum {
	SIM_SH64_SP_REGNUM = SIM_SH64_R15_REGNUM
	};

> After the general purpose registers, we want the program counter.
> Is this assignment OK with you?
> 
>> > !   SIM_SH64_PC_REGNUM   = SIM_SH64_R0_REGNUM+64,

No.  See above.

> Or do you want r63 to be assigned a number relative to r0, and then
> get automatically the next number for pc?
> 
> Or should we enumerate all 64 of the general purpose registers?

Yes.

> Similar considerations apply to the 64 control registers,
> 8 target registers, how to assign a number to fpscr, and
> the 64 floating point registers.

Andrew