On Thu, 3 Jan 2002, Emmanuel Dreyfus wrote:

> > setregs() calls setregs_o32() which calls setregs1() which does exactly
> > what setregs() used to do!!
> > This makes the common case suffer thru 2 extra function calls that do
> > absolutely nothing.
>
> I did it that way because if I ever have something to do in n32 that
> should not be done in n32, I just have to move it from setregs1 to
> setregs_o32. I'm not sure that we need to set t9 on n32, for instance.
>
> Next, setregs_o32 has this name to highlight this is o32. NetBSD native
> binaries need this to be called setregs, so if we suppress the function,
> then we end up with the o32 setregs function called setregs, and the n32
> setregs function called setregs_n32. This looks a bit weird.
>
> However, I'm not satisfied either with the way I did it in the patch, it
> should be improved.

I guess it boils down to different approaches to change.  Generally I say
"Lets cross that bridge when we come to it" instead of "building bridges
before we know thats what we want"

The t9 resister setup isn't much of a issue - it is a harmless write in
the N32 case, and it will take more instructions (~4) to determine if we
should optimise out one insn.   Nesting the function calls would be an
order of magniture worse!!!   You do the math....

Don't get me wrong - I am a great fan of self documenting code, but in
terms of code bloat - source code comments are always free!!

>
> > Could you not stick with the original setregs() and have setregs_{o,n}32
> > call it directly???  This removes 2 levels of function calls when
> > executing NetBSD binaries.
>
> What about inline'ing setregs1 and defining setregs as a macro, equal to
> setregs_o32? It seems to me that it will solve the performance issue
> while keeping the function names as clear as possible.

Not possible.   setregs is *referenced* from /sys/kern/kern_exec.c as an
element of 'struct emul emul_netbsd' - You cannot inline across source
files unless you stick it in a header file.  Even it that was inline, in
that particular case it needs a pointer to a function, therefore it cannot
be inline'd at all.

Also, the kernel is compiled with -O2, therefore it will not optimise
across function boundries at all.   Even if it did, it can only do it
within the same source module.

>
> > setregs_{o,n}32 may be better suited in the compat_irix sources which is
> > the reason for the requirement.
>
> I don't know, I understood that the goal was to get general N32 support
> for Mips. After all, we might need it for something else, who knows? And
> most of N32 support (syscall handler...) will not be in compat_irix
> sources anyway, so I'm not sure it's useful to move setregs function to
> compat_irix.

The way I see it - the N32 ABI is SGI only, which generally means it
belongs in the compat tree at this stage.

In order to change to N32 we need to have a suitable toolchain etc.  Once
we are further down that road we could easily move a dozen lines of code
from one kernel module to another (they are covered by the same copyright
in that case...)

Also, the 'setregs' function is what the MI layer expects to call.

Just my NZ$0.05 worth

-- 
Wayne Knowles			NetBSD/mipsco port maintainer
wdk@netbsd.org			http://www.netbsd.org