Toolchain for Maverick Crunch FPU

[Kai Ruottu]

Richard Earnshaw wrote:
> On Thu, 2007-04-12 at 14:16 +0300, Kai Ruottu wrote:
>   
>> Things seem to be that the '-mcpu=ep9312 -mhard-float' combination will 
>> crash the GCC build in both gcc-4.1.2 and gcc-4.2.0-20070316 prerelease 
>> like :
>>     
>
> -mhard-float doesn't do what you think it does...
>
> I think you should be using:
>
> 	-mcpu=ep9312 -mfpu=maverick -mfloat-abi=softfp
>
>   
Thanks, I implemented these default options for ep93xx in a separate 
'ep9312-elf' target, now
there was that common

   arm*-*-elf | ep9312-*-elf)

template in gcc/config.gcc.  The 'xscale-elf' (and '-coff') were 
separate already, so
putting the 'ep9312-*-elf' as a separate one with a separate 
'gcc/config/arm/t-ep9312-elf'
(derived from the 't-arm-elf') Makefile fragment for its (possibly) 
required multilibs, sounded
much simplier than touching the 'arm-elf' multilib definitions in the 
'gcc/config/arm/t-arm-elf'
(now made suitable for my self-chosen 'arm-elf' variations)...

It seemed to be that the changes I made in gcc-4.1.2 (here against the 
pristine gcc-4.1 snapshots) :

*** ../../gcc-4.1-20070409/gcc/config.gcc       Mon Oct 16 02:12:23 2006
--- ./config.gcc        Thu Apr 12 16:51:25 2007
***************
*** 2460,2466 ****
  if test x$with_float = x; then
        case ${target} in
        ep9312-*-*)
!               with_float=hard
                ;;
        esac
  fi
--- 2460,2467 ----
  if test x$with_float = x; then
        case ${target} in
        ep9312-*-*)
!               with_fpu=maverick
!               with_float=softfp
                ;;
        esac
  fi

didn't trigger the required '-D__SOFTFP__' but they triggered the 
'-D__MAVERICK__',
so just editing the 'gcc/config/arm/ieee754-[ds]f.S' to have a :

#if !defined (__VFP_FP__) && !defined(__SOFTFP__) && !defined(__MAVERICK__)

where the last one was earlier missing, seemed suitable for my lazy 
mind... So these three
predefines were taken meaning the same in this respect....  The 
'gcc/config.gcc' also required
a patch like :

***************
*** 2501,2507 ****
                done
                ;;

!       arm*-*-*)
                supported_defaults="arch cpu float tune fpu abi"
                for which in cpu tune; do
                        # See if it matches any of the entries in 
arm-cores.def
--- 2502,2508 ----
                done
                ;;

!       arm*-*-* | ep9312-*-*)
                supported_defaults="arch cpu float tune fpu abi"
                for which in cpu tune; do
                        # See if it matches any of the entries in 
arm-cores.def

in order to get those '--with-' options accepted for 'ep9312-*' too...

 The main 'config.sub' also required adding the 'ep9312' as an accepted 
CPU type.  After
these fixes the configure and build succeeded...  Please correct me if 
something sounds
still being wrong!

 The resulted compiler now replaces some opcodes with others like :

*** fp_ep9312-2.s       Wed Apr 11 22:12:43 2007
--- fp_ep9312-3.s       Thu Apr 12 21:38:35 2007
***************
*** 30,36 ****
        ldr     r0, [r5, #0]    @ float
        ldr     r1, [r2, #0]    @ float
        bl      __divsf3
!       cfstrs  mvf0, [r4, #0]
        cfldrs  mvf0, [r4, #0]
        cfldrs  mvf1, [r5, #0]
        cfadds  mvf0, mvf0, mvf1
--- 30,36 ----
        ldr     r0, [r5, #0]    @ float
        ldr     r1, [r2, #0]    @ float
        bl      __divsf3
!       str     r0, [r4, #0]    @ float
        cfldrs  mvf0, [r4, #0]
        cfldrs  mvf1, [r5, #0]
        cfadds  mvf0, mvf0, mvf1


when compared to the earlier 'arm-elf' targeted one with '-mcpu=ep9312 
-mhard-float'...
For me it looks like '__divsf3' now returning something in register 'r0' 
instead of 'mvf0'.

 To get the 'arm-elf' one to produce code with your '-mcpu=ep9312 
-mfpu=maverick
-mfloat-abi=softfp' when getting the bare '-mcpu=ep9312' should succeed 
via tinkering
the settings for 'specs', I remember once enabling the '-msoft-float' 
for 'i386-elf' and I
remember this also requiring the '-mno-fp-ret-in-387' or something to 
tell that there
really wasn't any 'i387' present with its FPU-registers as default....