ath hal and reserved register r23

Apparently the changes from the yamt-idlelwp branch reserve
MIPS register
r23 for curlwp for a kernel size/(speed?) benefit.  The
Atheros HAL,
which we do not have the liberty to recompile, uses r23 for
its own
purposes, which clash with the kernel's.  Consequently, one
cannot use
ath(4) on a MIPS box running -current.

Is it possible either to use some other register, or to make
the use of
r23 for curlwp a compile-time option, so that development in
-current
on MIPS boxen such as the Meraki Mini[1] can continue?

Dave

[1] Based on an Atheros MIPS SoC. 

-- 
David Young             OJC Technologies
dyoungojctech.com      Urbana, IL * (217) 278-3933 ext 24

On Tue, Jul 24, 2007 at 03:25:21PM -0500, David Young
wrote:
> Is it possible either to use some other register, or to
make the use of
> r23 for curlwp a compile-time option, so that
development in -current
> on MIPS boxen such as the Meraki Mini[1] can continue?

Making it a kernel option should be easy.

Martin

On Tue, Jul 24, 2007 at 10:38:02PM +0200, Martin Husemann
wrote:
> On Tue, Jul 24, 2007 at 03:25:21PM -0500, David Young
wrote:
> > Is it possible either to use some other register,
or to make the use of
> > r23 for curlwp a compile-time option, so that
development in -current
> > on MIPS boxen such as the Meraki Mini[1] can
continue?

I just asked Sam Leffler if he could recompile it. I should
have done that a
lot earlier, I'm sorry.
 
> Making it a kernel option should be easy.

The main bit of work there is adjusting the assembly code. A
very short term
option is to edit the object file to use %gp in place of
%s7. That's grotty
but I think it would work. I'll investigate both this
week-end.

Andrew

>>>>> "Stephen" == Stephen M Rumble
<stephen.rumbleutoronto.ca> writes:

 Stephen> Quoting David Young <dyoungpobox.com>:
 >> Apparently the changes from the yamt-idlelwp
branch reserve MIPS
 >> register r23 for curlwp for a kernel size/(speed?)
benefit.  The
 >> Atheros HAL, which we do not have the liberty to
recompile, uses
 >> r23 for its own purposes, which clash with the
kernel's.
 >> Consequently, one cannot use ath(4) on a MIPS box
running
 >> -current.
 >> 
 >> Is it possible either to use some other register,
or to make the
 >> use of r23 for curlwp a compile-time option, so
that development
 >> in -current on MIPS boxen such as the Meraki
Mini[1] can continue?

 Stephen> Isn't the reservation of r23 just a single GCC
flag? Since
 Stephen> Sam builds the HALs for a bunch of platforms
anyhow, maybe
 Stephen> if it's not complicated he'd be willing to add
one more
 Stephen> image to his builds.

r23 is s7, and that has been a "preserved across
function calls"
register in the standard MIPS ABI forever.  I can't think of
any
switch to GCC to treat it differently.  (I'm sure it could
be done
with a change to the code generator, probably a fairly easy
one, but I
wouldn't expect it to be a feature of any standard
compiler.)

I suppose it would be possible to hack code, or hack the
compiler, to
accommodate someone who is violating this ABI, but if they
are so
badly confused, what else did they get wrong?  Wouldn't it
make more
sense to say "hey, go fix your broken code"?

      paul

On Tue, Jul 24, 2007 at 04:58:42PM -0400, Paul Koning
wrote:

> r23 is s7, and that has been a "preserved across
function calls"
> register in the standard MIPS ABI forever.

True but the Atheros HAL still cannot change it (even if it
restores it) as
interrupt handlers can legitimately inspect the value of
curlwp. They rely
on it to point to an lwp structure.

Andrew

>>>>> "Andrew" == Andrew Doran
<adnetbsd.org> writes:

 Andrew> On Tue, Jul 24, 2007 at 04:58:42PM -0400, Paul
Koning wrote:
 >> r23 is s7, and that has been a "preserved
across function calls"
 >> register in the standard MIPS ABI forever.

 Andrew> True but the Atheros HAL still cannot change it
(even if it
 Andrew> restores it) as interrupt handlers can
legitimately inspect
 Andrew> the value of curlwp. They rely on it to point to
an lwp
 Andrew> structure.

But that way of using S7 isn't ABI conformant.  The ABI says
a
function can use it but must restore it on exit.  If you
change that
to say the register must at all times point to foo, that's
nonstandard.

>>>>> "Stephen" == Stephen M Rumble
<stephen.rumbleutoronto.ca> writes:

 >>  r23 is s7, and that has been a "preserved
across function calls"
 >> register in the standard MIPS ABI forever.  I
can't think of any
 >> switch to GCC to treat it differently.  (I'm sure
it could be done
 >> with a change to the code generator, probably a
fairly easy one,
 >> but I wouldn't expect it to be a feature of any
standard
 >> compiler.)

 Stephen> I think it's just '-ffixed-23'.

Not in the stock GCC...

 >> I suppose it would be possible to hack code, or
hack the compiler,
 >> to accommodate someone who is violating this ABI,
but if they are
 >> so badly confused, what else did they get wrong? 
Wouldn't it make
 >> more sense to say "hey, go fix your broken
code"?

 Stephen> Since we control (most of) the kernel, we don't
really have
 Stephen> to follow any ABI, no?

You still do, unless (a) you want to have a nonstandard
compiler and
(b) you are willing to rewrite any assembly language code or
binary
code that comes in from the outside and expects its
environment to
conform to some known ABI.

Is that kind of trouble worth having an xyz pointer wired
into one of
the GPRs?  It's not at all clear that it increases
performance at all,
much less by an interesting amount.

     paul

On Wed, Jul 25, 2007 at 10:18:42AM -0400, Paul Koning
wrote:

> But that way of using S7 isn't ABI conformant.

The kernel doesn't have to be ABI conformant.

>  Stephen> I think it's just '-ffixed-23'.
> 
> Not in the stock GCC...

http://gcc.gnu.org/onlinedocs/
gcc-4.2.1/gcc/Code-Gen-Options.html#Code-Gen-Options

Andrew

On Wed, Jul 25, 2007 at 11:02:46AM -0400, Stephen M. Rumble
wrote:

> I don't know if it's worth having. I guess it depends
on how many  
> binary blobs we expect to encounter (and I assume this
is a very low  
> number). On the other hand, I'm sure it was not just
changed for the  
> heck of it.
> 
> Andrew, what was the reason for this change?
Performance? Code  
> simplicity? Is this just a common thing to do? I'm
simply curious.

A lot of this is in the archives, but in short:

It's the most commonly used variable in the kernel, and the
frequency of its
use is increasing significantly. If we get around to making
system calls use
the standard C calling convention (this is actually of real
benefit) then we
grow a whole new set of uses. For SMP, it's also the most
convenient way to
identify the running CPU.

Andrew

On Jul 26, 2007, at 4:01 AM, Andrew Doran wrote:

> (this is actually of real benefit)

And it's not really possible to understate how much benefit
there is  
to doing so.  It's huge.

-- thorpej