[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)