> On Thu, 26 Oct 2000, Mike Pumford wrote:
> 
> > > On Thu, 26 Oct 2000, David Brownlee wrote:
> > >
> > > 	Just a thought on this - how much of a gain would it be for
> > > 	StrongARM RiscPC machines to be able to use the non halfword
> > > 	StrongARM instructions? Would there be any sense in adding another
> > > 	-march or similar option to gcc?
> > >
> > I think that is what -march=armv3m means. It allows the use of the
> > enhanced multiply instructions but inhibits the halfword load/store
> > instructions. The -mtune=strongarm option enables the instruction
> > reordering to reduce result register dependencies.
> >
> 	That looks pretty consistent with a quick browse of
> 	dist/gcc/config/arm/arm.[ch] :)
> 
>   {"armv3m",    PROCESSOR_NONE, (FL_CO_PROC | FL_FAST_MULT | FL_MODE32
>                                  | FL_MODE26)},
> 
>   {"strongarm", PROCESSOR_STARM, (FL_FAST_MULT | FL_MODE32 | FL_MODE26
>                                   | FL_ARCH4)},
> 
> 	Hmm... -marmv3m also implies FL_CO_PROC, which by default will
> 	compile for an FPE. Kernel code is always compiled soft-float,
> 	does the same apply for NetBSD/arm32 userland?

NetBSD always uses soft-float, so the co-proc flag won't affect anything.

> 
> 	Are there any other interesting armv4 instructions?

The only thing that you lose between -march=armv3m and -march=armv4 that 
would be of value on a SA+RPC is ldrsb.  Given that adding this would only 
have minimal affect on normal user code, there seems little point in 
adding a special option just to work around the RPCs obsolete bus 
architecture.

R.