[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[MiNT] gcc-4.5.2-mint-20110128



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)