GBR on Hitachi SH

GBR on Hitachi SH

[Aaron Passey]

Hi,

	I am writing a small, multitasking operating system for the Hitachi SH1
processor.  I would like to use the GBR (Global Base Register) as a pointer to
my current task struct in the kernel but I need to make sure that egcs never
uses that register normally.  Also, if egcs does not normally use that
register, is there an asm() directive I can use to make accesses to the current
task struct efficient?  There are a couple of addressing modes using the GBR
that would be nice if egcs used.

For example, if I declare my current pointer as:
struct task {
	struct regset *regs;
	int state;
	/* ... */
};

register struct task *current asm ("gbr");

and I do:
current->state = 10;

Will the compiler be smart enough to generate:
mov     #10, r0
mov.l   r0, @(1, GBR)


Thanks,

Aaron

Re: GBR on Hitachi SH

[Jeffrey A Law]

  In message < slrn6ks2nm.g8e.aaronp@ofb.net >you write:
  > Hi,
  > 
  > 	I am writing a small, multitasking operating system for the Hitachi SH1
  > processor.  I would like to use the GBR (Global Base Register) as a pointer
  >  to my current task struct in the kernel but I need to make sure that egcs never
  > uses that register normally.  Also, if egcs does not normally use that
  > register, is there an asm() directive I can use to make accesses to the current
  > task struct efficient?  There are a couple of addressing modes using the GBR
  > that would be nice if egcs used.
You can prevent the compiler from using most registers, please
refer to the gcc manual.  Specificly look at the -ffixed-<reg>
switch.



jeff

Re: GBR on Hitachi SH

[Joern Rennecke]

>   > 	I am writing a small, multitasking operating system for the Hitachi SH1
>   > processor.  I would like to use the GBR (Global Base Register) as a pointer
>   >  to my current task struct in the kernel but I need to make sure that egcs never
>   > uses that register normally.  Also, if egcs does not normally use that
>   > register, is there an asm() directive I can use to make accesses to the current
>   > task struct efficient?  There are a couple of addressing modes using the GBR
>   > that would be nice if egcs used.
> You can prevent the compiler from using most registers, please
> refer to the gcc manual.  Specificly look at the -ffixed-<reg>
> switch.

In the case of the GBR for the Hiatchi SH, this is not necessary;
the GBR is already a fixed register.

Re: GBR on Hitachi SH

[Joern Rennecke]

> Hi,
> 
> 	I am writing a small, multitasking operating system for the Hitachi SH1
> processor.  I would like to use the GBR (Global Base Register) as a pointer to
> my current task struct in the kernel but I need to make sure that egcs never
> uses that register normally.  Also, if egcs does not normally use that
> register, is there an asm() directive I can use to make accesses to the current
> task struct efficient?  There are a couple of addressing modes using the GBR
> that would be nice if egcs used.
> 
> For example, if I declare my current pointer as:
> struct task {
> 	struct regset *regs;
> 	int state;
> 	/* ... */
> };
> 
> register struct task *current asm ("gbr");
> 
> and I do:
> current->state = 10;
> 
> Will the compiler be smart enough to generate:
> mov     #10, r0
> mov.l   r0, @(1, GBR)

No.  It doesn't know about gbr-relative adddressing modes.
And even if you teach it about them, you will find that things
that need r0 are tricky, since r0 is also the return register for
integer values, and reload is not particularily good at handling
registers that might be used for returning values.

Re: GBR on Hitachi SH

[Aaron Passey]

> > For example, if I declare my current pointer as:
> > struct task {
> > 	struct regset *regs;
> > 	int state;
> > 	/* ... */
> > };
> > 
> > register struct task *current asm ("gbr");
> > 
> > and I do:
> > current->state = 10;
> > 
> > Will the compiler be smart enough to generate:
> > mov     #10, r0
> > mov.l   r0, @(1, GBR)
> 
> No.  It doesn't know about gbr-relative adddressing modes.
> And even if you teach it about them, you will find that things
> that need r0 are tricky, since r0 is also the return register for
> integer values, and reload is not particularily good at handling
> registers that might be used for returning values.

	Would anyone else find this useful?  How hard is it to add? It
seems like this register would be almost completely useless without this
support in the c compiler.  I can certainly make assembly macros to access
it but that doesn't seem like it'd be all that efficient or convienient.
They'd look something like:

inline long __getLong(int offset) {
	long retval;
	asm("mov.l @(%1, GBR), %0" :
		"=r0" (retval) : "i" (offset));
	return retval;
}

and you could even be super clever and define a macro that takes the
element name:
#define getLong(name) __getLong(offsetof(struct task, name))

	You'd need a different macro for every load and store of each size
(8, 16, and 32 bits).  Plus if I change the size of any member of my
struct, it'll messup.  This seems like it's too much work.  I guess I'll
probably steal another register for this purpose or just use a memory
location.  Are there any of the general purpose registers that are
better to steal?  I'm guessing that any of r8-r14 would be best.


Thanks for the help,

Aaron

Re: GBR on Hitachi SH

[Jim Wilson]

Gcc does not use the GBR register.  So you are free to use it yourself.

Gcc is not aware of GBR based addressing modes, so you won't be able to 
make gcc generate them without modifying gcc to add them.  You would need
to modify GO_IF_LEGITIMATE_ADDRESS to do this.

Gcc has no register class for the gbr, so there is no way to specify it in
an asm.  You would have to add a register class and assorted related info
to get this working.

Gcc does know the register name, so you might be able to use __asm__ ("gbr")
or something similar to assign a variable to the gbr register.  However, this
isn't of much use unless you fix the above problems, since otherwise gcc won't
know how to generate code to access the gbr register.  You would have to write
explicit asms, or write assembly language code, in order to do anything with
gbr.

Jim

Re: GBR on Hitachi SH

[Joern Rennecke]

> 	You'd need a different macro for every load and store of each size
> (8, 16, and 32 bits).  Plus if I change the size of any member of my
> struct, it'll messup.  This seems like it's too much work.  I guess I'll

That's not true.  You can conditionalize on the size of the member,
inside the macro.