[MiNT] gcc-4.5.2-mint-20110128

[Vincent Rivière <vincent.riviere@freesbee.fr>]

Hello.

Recently, I have asked for comments about 2 important compatibility issues 
regarding GCC: register used to return floats and define to indicate using 
the FPU. I got some answers, but no agreement has been found.
Since the whole toolchain was broken for -m68020-60, I made decisions myself 
to unlock the situation.

The result is gcc-4.5.2-mint-20110128. As usual, the patches, Cygwin and 
Ubuntu cross-binaries are available on my website:
http://vincent.riviere.free.fr/soft/m68k-atari-mint/

The main changes are:

1) With -m68020-60, floats are returned into d0/d1, exactly as other 
configurations. I believe this was the case in ancient GCC versions, but GCC 
2.95.3 was configured to return floats to fp0, as well as previous versions 
of GCC 4.x.
As a result, mixing -m68000 and -m68020-60 libraries is now *allowed*. 
Consider this as good or bad news, as you wish.
This new method for returning floats is theoretically a bit slower than 
before, but I didn't manage to see significant performance change. So we can 
consider there is no big problem here.
The MiNTLib and PML were already configured for this "new" behavior, so I 
only had do make a very simple change in GCC's config file.
For memory, I had to *remove* some lines from gcc/config/m68k/mint.h. See 
the attached float.txt to see what I have removed.

2) When generating code for the 680x0 FPU, GCC defines __HAVE_68881__. By 
mistake, this define was missing in GCC 2.95.3. That old compiler defined 
the nonstandard __M68881__ instead. Now, GCC 4.x defines __M68881__ whenever 
__HAVE_68881__ is defined. This allows to compile old code (MiNTLib, PML) as 
is, before it is fixed with the new define.

3) As a pleasant side effects, GCC's math-68881.h is now used transparently. 
For example, it you include math.h and use sin(), the function call will be 
inlined to a single fsind instruction, for optimal speed.

4) As a side effect of 1), new code compiled with -m68020-60 will be 
incompatible with old -m68020-60 libraries. Since this configuration was 
partially broken, it probably doesn't matter.

5) I have compiled all the libraries provided by GCC with 
-fomit-frame-pointer. So there will be no more useless LINK/UNLK in your 
executables :-) Actually, there will be a few ones: they come from manually 
written assembler code inside GCC.

6) I have compiled all the GCC libraries without -g. It was pretty useless 
anyway, because it would require the sources to debug the libraries. We have 
won a few megabytes.

As as proof of concept, I have compiled POV-Ray with -m68000 (default), 
-m68020-60 (68020 + FPU) and -mcpu=5475 (ColdFire V4e + FPU), all the 3 
versions work well and produce superb images.
This is a good testcase because POV-Ray uses intensively the math functions.
http://vincent.riviere.free.fr/soft/m68k-atari-mint/archives/mint/povray/

I hope this is a new step towards modernity.

--
Vincent Rivière

/* Define how to generate (in the callee) the output value of a
   function and how to find (in the caller) the value returned by a
   function.  VALTYPE is the data type of the value (as a tree).  If
   the precise function being called is known, FUNC is its
   FUNCTION_DECL; otherwise, FUNC is 0.  */

#define FUNCTION_VALUEX(MODE) \
  gen_rtx_REG ((MODE), (TARGET_68881 && FLOAT_MODE_P (MODE) ? 16 : 0))

#undef FUNCTION_VALUE
#define FUNCTION_VALUE(VALTYPE, FUNC) \
  FUNCTION_VALUEX (TYPE_MODE (VALTYPE))

/* Define how to find the value returned by a library function
   assuming the value has mode MODE.  */

#undef LIBCALL_VALUE
#define LIBCALL_VALUE(MODE) \
  FUNCTION_VALUEX (MODE)

/* 1 if N is a possible register number for a function value.  */

#undef FUNCTION_VALUE_REGNO_P
#define FUNCTION_VALUE_REGNO_P(N) \
  ((N) == D0_REG || (TARGET_68881 && (N) == FP0_REG))

/* Define this to be true when FUNCTION_VALUE_REGNO_P is true for
   more than one register.  */

#undef NEEDS_UNTYPED_CALL
#define NEEDS_UNTYPED_CALL (TARGET_68881)