Services - tools - models - for embedded software development
Embecosm divider strip
Prev  Next

4.2.4.  OpenRISC 1000 Register Architecture

The register architecture is defined by two groups of struct gdbarch functions and fields. The first group specifies the number of registers (both raw and pseudo) and the register numbers of some "special" registers.

set_gdbarch_pseudo_register_read  (gdbarch, or1k_pseudo_register_read);
set_gdbarch_pseudo_register_write (gdbarch, or1k_pseudo_register_write);
set_gdbarch_num_regs              (gdbarch, OR1K_NUM_REGS);
set_gdbarch_num_pseudo_regs       (gdbarch, OR1K_NUM_PSEUDO_REGS);
set_gdbarch_sp_regnum             (gdbarch, OR1K_SP_REGNUM);
set_gdbarch_pc_regnum             (gdbarch, OR1K_PC_REGNUM);
set_gdbarch_ps_regnum             (gdbarch, OR1K_SR_REGNUM);
set_gdbarch_deprecated_fp_regnum  (gdbarch, OR1K_FP_REGNUM);
	  

The second group of functions provides information about registers.

set_gdbarch_register_name         (gdbarch, or1k_register_name);
set_gdbarch_register_type         (gdbarch, or1k_register_type);
set_gdbarch_print_registers_info  (gdbarch, or1k_registers_info);
set_gdbarch_register_reggroup_p   (gdbarch, or1k_register_reggroup_p);
	  

The representation of the raw registers (see Section 2.3.5.3) is: registers 0-31 are the corresponding GPRs, register 32 is the previous program counter, 33 is the next program counter (often just called the program counter) and register 34 is the supervision register. For convenience, constants are defined in the header, or1k_tdep.h, for all the special registers.

#define OR1K_SP_REGNUM         1
#define OR1K_FP_REGNUM         2
#define OR1K_FIRST_ARG_REGNUM  3
#define OR1K_LAST_ARG_REGNUM   8
#define OR1K_LR_REGNUM         9
#define OR1K_RV_REGNUM        11
#define OR1K_PC_REGNUM       (OR1K_MAX_GPR_REGS + 0)
#define OR1K_SR_REGNUM       (OR1K_MAX_GPR_REGS + 1)
	  

In this implementation there are no pseudo-registers. A set could have been provided to represent the GPRs in floating point format (for use with the floating point instructions), but this has not been implemented. Constants are defined for the various totals

#define OR1K_MAX_GPR_REGS    32
#define OR1K_NUM_PSEUDO_REGS  0
#define OR1K_NUM_REGS        (OR1K_MAX_GPR_REGS + 3)
#define OR1K_TOTAL_NUM_REGS  (OR1K_NUM_REGS + OR1K_NUM_PSEUDO_REGS)
	  
[Caution]Caution

These totals are currently hard-coded constants. They should really draw on the data in the struct gdbarch_tdep, providing support for architectures which have less than the full complement of 32 registers. This functionality will be provided in a future implementation.

One consequence of providing no pseudo-registers is that the frame pointer variable, $fp in GDB will not have its correct value. The provision of this register as an intrinsic part of GDB is no longer supported. If it is wanted then it should be defined as a register or pseudo-register.

However if there is no register with this name, GDB will use either the value of the deprecated_fp_regnum value in struct gdbarch or the current frame base, as reported by the frame base sniffer.

For the time being, the deprecated_fp_regnum is set. However the longer term plan will be to represent the frame-pointer as a pseudo-register, taking the value of GPR 2.

The register architecture is mostly a matter of setting the values required in struct gdbarch. However two functions, or1k_pseudo_register_read and or1k_pseudo_register_write are defined to provide access to any pseudo-register. These functions are defined to provide hooks for the future, but in the absence of any pseudo-registers they do nothing.

There are set of functions which yield information about the name and type of registers and which provide the output for the GDB info registers command.

Embecosm divider strip