Ian Dall wrote:

> Simon Burge <simonb@wasabisystems.com> writes:
> 
>   > I have managed to build a kernel with current gcc and binutils.  Most
>   > files built with -O2, but I needed a build a couple with -O1 to avoid
> 
>   > 	internal compiler error: in general_operand, at recog.c:1023
> 
>   > type errors.
> 
> What FSF Version does this correspond to? The NetBSD CVS repository
> still seems to be at 2.95.3.

When I said "current gcc and binutils", I meant gcc-current and
binutils-current, cvs updated just a couple of days ago.  I'm using:

	thoreau 116> ns32k-netbsd-gcc -v
	Reading specs from /usr/local/lib/gcc-lib/ns32k-netbsd/3.3/specs
	Configured with: ../gcc/configure --target=ns32k-netbsd
	Thread model: single
	gcc version 3.3 20021123 (experimental)


	thoreau 122> ns32k-netbsd-as --version
	GNU assembler 2.13.90 20021124
	...
	This assembler was configured for a target of `ns32k-pc532-netbsd'.


>   > I also needed to change <machine/cpufunc.h> in the movs macro:
> 
>   > -               : "r0", "memory" \
>   > +               : /* XXX "r0", XXX */ "memory" \
> 
> I wonder if that is valid? R0 has zero in after a movs instruction. If
> you don't tell the compiler it has been clobbered, the optimiser can
> assume it still has "n" in it. Now it looks like one should get away
> with it because movs is always used in a "do { ... } while (0);"
> construct and the r0 local variable is never used again within
> scope. But, it is not clear to me that that is effectively telling the
> compiler the variable is clobbered.
> 
> Suppose r0 already had the value n in it as follows: 
> 
>   int count;	  /* Happens to allocate r0 */
> 
>   ...
> 
>   do {
>            /* Expand movs macro */
> 	    register int r0 __asm ("r0") = count;  /* becomes a no-op */
>            ...
>   } while 0;
> 
>   /* Use "count", which now has zero in it, expecting to be unchanged */
> 
> I compiled the kernel on a later gcc without changing this macro.

See above; this is with gcc 3.3 20021123.

I see the problem, but don't know enough about asm constraints to work
out how to get around it.  What about simply marking r0 as both an input
and output register?  Being an output register as well, wouldn't this
effectively mark it as "clobbered"?

Btw, is there a good ns32k instruction set reference anywhere?  I
currently only have my ns32k series databook, which has the instruction
listing, but is not a reference.

>   > Jason Thorpe mentioned that he thought there was still one codegen problem
>   > outstanding ("Hard registers in RTL templates, -fomit-frame-pointer" on
>   > the gcc lists?).
> 
> That was fixed. I haven't had the time to work on this lately, but I
> am not aware of any outstanding ns32k specific bugs in the FSF current
> gcc as of a several months ago. Most of the changes could be
> backported to earlier versions fairly easily though this would have to
> be tested and is not the most rewarding thing in the world to do. I
> was going to do it myself, but it took a long time to get my
> "developer" paperwork, and I still haven't returned it.

I think it's safe to say that we can target gcc 3.3 for ns32k
cross-building, and wasting time back-porting to older gcc versions
probably isn't worth the effort.

Simon.
--
Simon Burge                            <simonb@wasabisystems.com>
NetBSD Support and Service:         http://www.wasabisystems.com/