[U-Boot-Users] [patch u-boot git 2/3] better ARM9 compiler options

[David Brownell <david-b@pacbell.net>]

On Monday 21 January 2008, Ulf Samuelsson wrote:
> > --- u-boot.orig/cpu/arm920t/config.mk 2008-01-13 10:42:55.000000000 -0800
> > +++ u-boot/cpu/arm920t/config.mk 2008-01-13 11:05:02.000000000 -0800
> > @@ -24,11 +24,11 @@
> > PLATFORM_RELFLAGS += -fno-strict-aliasing  -fno-common -ffixed-r8 \
> >  -msoft-float
> 
> Why not remove the "-msoft-float" as well.
> U-Boot does not use soft float

It shouldn't use floating point of any flavor, in fact.
But when some accident makes it try to do so, "soft" is
the only potentially safe approach.


> and why then the requirement to  
> use a compiler which supports soft-float???

That change would be orthogonal.  And potentially troublesome; I
have seen build breakage in U-Boot that was fixed by disabling
even the accidental use of hard-float code.


> > --- u-boot.orig/cpu/arm926ejs/config.mk 2008-01-13 10:42:55.000000000 -0800
> > +++ u-boot/cpu/arm926ejs/config.mk 2008-01-13 11:04:56.000000000 -0800
> > @@ -24,11 +24,11 @@
> > PLATFORM_RELFLAGS += -fno-strict-aliasing  -fno-common -ffixed-r8 \
> >  -msoft-float
> > 
> > -PLATFORM_CPPFLAGS += -march=armv4
> > # =========================================================================
> > #
> > # Supply options according to compiler version
> > #
> > # =========================================================================
> > +PLATFORM_CPPFLAGS +=$(call cc-option,-mcpu=arm926ej-s,-march=armv4)
> > PLATFORM_CPPFLAGS +=$(call cc-option,-mapcs-32,-mabi=apcs-gnu)
> > PLATFORM_RELFLAGS +=$(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,))
> > 
> 
> 
> Is this correct?

Sure.  If that fallback is used, it's just a fallback to sub-optimal
code generation.  No CLZ, probably the wrong guesses about pipelines,
and so on.  But probably still safe on ancient compilers.


> ARM926EJ-S is ARMV5 architecture, not ARMV4.

In fact it's ARMv5tej ... an ARMv4 superset.

The specific compiler warnings that annoyed me would vanish by passing
an "armv4t" option ... that'd be OK on most CPUs that U-Boot supports.
But I don't see much reason not to specify the actual CPU, and thus to
get the benefit of smarter scheduling on newer compilers.

- Dave