On Fri, 20 Apr 2007, Jochen Kunz wrote:

> On Thu, 19 Apr 2007 15:05:22 -0400
> Michael Lorenz <macallan@netbsd.org> wrote:
> 
> > Hmm, some of the assembly changes probably need to be reverted for 
> > 32bit sparc.
> Or ffb_accel.c should use #ifdef __sparc_v9__ to switch between V9 ASM
> and V7/V8 ASM? ENOSPARCCLUE | ENOX11CLUE
> 
> > Umm, this module should live somewhere in src/x11/Xserver/hw/xfree86, 
> > probably needs to be enabled in another Makefile.
> I enabled xf8_32wid, rebuild, instaled the X11 sets and bingo!
> I now have a working Xserver on the U2 in 32 bit mode.
> Thanks for your help. :-)
> 
> > > I am currently running a clean rebuild with -mcpu=v9. It failed in
> > > Mesa because some #ifdef asumes __sparc_v9__ == 64 bit. Maybe it is
> > > not a good idea to build sparc with -mcpu=v9?
> > Yeah, assumptions like that will be all over the place. Maybe v8plus
> > is  more like it.
> Yes, AFAIK v8(plus) is the usual choice for optimazion. I choose v9 to
> get past the V9 ASM Problem in ffb_accel.c. Meanwhile I did a complete
> build with -mcpu=v9 and instaled the result. The mentioned file in Mesa
> was the only trouble maker.

Woah there.

If you specify -mcpu=v9 to gcc it will both enable V9 instructions 
and switch to a 64-bit memory model, which is probably not what you want.  
That will generate ELF64 object files which cannot be linked with ELF32 
binaries, use the full LP64 programming model, as well as a 64-bit stack 
which will cause alignment errors if you ever managed to try to execute 
that code.

I think the proper ISA to use for v9 instructions with a 32-bit memory 
model would be -mcpu=v8plusa (v8 + "plus" v9 insns + "a" UltraSPARC 
extensions).  Take a look at the config files for building a 32-bit 
kernel.  It uses the same setup with a 32-bit address space but V9 
instructions with UltraSPARC extensions.

Now the xfree86 server has some issues.  Originally designed for the Linux 
sparc64 port, there is some confusion on the proper use of gcc ABI 
definitions.  __sparc_v9__ should be used to determine whether the 
assembler is allowed to generate V9 instructions.  __arch64__ (or is it 
__arch_64__?  I forget) should be used to determine whether to use a 
64-bit memory model and stack.

When you try to specify the memory model to gcc, the compiler will 
sometimes get confused.  I haven't used the latest compilers, so YMMV.  
It used to be that you needed a completely different compiler set to 
generate 32-bit code and 64-bit code, but binutils could be shared.  You 
may need to use the standard -m32 with gcc, but pass the v8plusa flag to 
the assembler directly, bypassing cc1 with `-Wa,-Av8plusa'.  Once again, 
look at the kernel makefiles which seem to be using:

 -m32 -Wa,-Av8plusa -mcpu=ultrasparc


Eduardo