Amiga.org
Amiga News and Community Announcements => Amiga News and Community Announcements => Amiga Software News => Topic started by: bernd_afa on May 11, 2010, 01:33:27 PM
-
Here you can download the GCC 4.5.0 Verion.It contain C and C++ Compiler.
http://amiga.sourceforge.net
In this archive is also docs and the additional backend sources to build from the offical GCC sources any GCC 68k Version with only 1-2 minutes of typing/copying work.
The C++ includes and libs can download from other link.
-
Nice :)
When you say it's "without C++", do you mean it doesn't include any precompiled standard C++ libraries for m68k, or something else?
-
"-mregparm" is fixed for working in this new release ?
-
"-mregparm" is fixed for working in this new release ?
the Versions are clean GCC builds from offical source.They dont contain the inoffical AOS Hacks that work buggy and so not add in GCC Main source.If somebody want add this features he can do that(which is of course lots work), i need that not and so i dont want spend time to do that.
-regparms is obsolete in newer compilers, because functions that are short and so get a speedup with -regparms do inline in GCC with -O3 or declare as
__attribute__((always_inline)) which is support since GCC 3.1
Newer GCC as 2.x can inline over a linked lib. and thats faster as when use -regparms
to see what functions are usefull to optimize to increase the noticable speed of a program you can use with ixemul V63 gprof.
-
>When you say it's "without C++", do you mean it doesn't include any precompiled >standard C++ libraries for m68k, or something else?
the archives are splittet in compiler exe/which contain C++ and C) and includes+ libs.
the split is done, because maybe somebody else compile the gcc to another platform.
so the compiler archive need not contain the includes and libs.
http://amiga.sourceforge.net/phps/logger.php?download=include-20090222.lha
The C++ libs/includes can btw use with compilers from 3.4.0 upto newest without Problems
-
Newer GCC as 2.x can inline over a linked lib.
Could you elaborate a bit? GCC 3 certainly didn't do LTO, if that's what you mean. As far as I can tell it was only added in 4.5.
-
the Versions are clean GCC builds from offical source.They dont contain the inoffical AOS Hacks that work buggy and so not add in GCC Main source.
I'm not so sure if that was the reason they weren't included. When GCC went thru massive changes no-one just wasn't around to port them and they weren't seen as important enough to keep around.
In fact, now that I think about it: Were they ever even included in the main gcc tree? I remember gcc "amiga" patchsets from long long ago.
-
Could you elaborate a bit? GCC 3 certainly didn't do LTO, if that's what you mean. As far as I can tell it was only added in 4.5.
LTO is optimizing over whole code.
the compiler optimizer see the whole code of main and lib and can optimize.I have not test LTO on 4.5 if that work.maybe need a special linker.
its a hard to find a real world example that optimize better thru this.
maybe for PPC CPU with the many registers and worse out of order execution, it speedup more.
but what work since GCC 3 is the inline of a lib func so for short funcs you need no calls and so need not pass the registers on stack or register.-mrepparms is then obsolete and do no speedup.
I do tests with the ixemul libc.a some time ago.
the sourcercode in libc.a is this
__attribute__((always_inline)) inline double hypot(double x,double y)
{
return sqrt(x*x+y*y);
}
this is the main source and create a ixemul prog (because only link with -ldebug)
#include
main(int argv,int argc)
{
double value;
value=hypot(argc,argv);
kprintf("%f\n",value);
}
I compile with -O1.
when i load the compiled exe in asm debugger it look as this.You see there is no call do and all is inline.
_main
+0000(10E33D22): LINK A5,#-$48
+0004(10E33D26): MOVEM.L D2-D3/A6,-(A7)
+0008(10E33D2A): BSR.L ___main ;10E340
+000E(10E33D30): FMOVE.L $C(A5),FP0
+0014(10E33D36): FMOVE.L 8(A5),FP1
+001A(10E33D3C): FMUL.X FP0,FP0
+001E(10E33D40): FMUL.X FP1,FP1
+0022(10E33D44): FADD.X FP1,FP0
+0026(10E33D48): FSQRT.X FP0
+002A(10E33D4C): FMOVE.D FP0,-(A7)
+002E(10E33D50): PEA _moncontrol+4(PC) ;10E33C84
+0032(10E33D54): BSR.L _kprintf ;10E33F74
-
I'm not so sure if that was the reason they weren't included. When GCC went thru massive changes no-one just wasn't around to port them and they weren't seen as important enough to keep around.
In fact, now that I think about it: Were they ever even included in the main gcc tree? I remember gcc "amiga" patchsets from long long ago.
No, they never was add, it is not in the 68k tree.
The register to variabale feature on AOS is only a hack to stay more compatible with sasc.It work not in C++ compile mode.
GCC have a way to load register into variable.only the programs need change.a SDI that handle it for MUI programs is also in the includes.
other programs can change easy, stormmesa for GCC use too the offical GCC register to variable feature
and the regparm thing dont work well, i never get a program running.
maybe this indicate that regparm is not need because not measurable speedup and as far i know X86 is the only target that have offical the regparm switch.
curios X86 have few register, better is maybe for RISC or use PPC always regparm now ?
I remember only warpup and powerup time, with GCC 2.xx.Here i see the parameter are put on stack.
-
LTO is optimizing over whole code.
I know what LTO does. It wasn't included in gcc3.
I have not test LTO on 4.5 if that work.maybe need a special linker.
According to documentation (http://gcc.gnu.org/wiki/LinkTimeOptimization#Requirements) you don't.
but what work since GCC 3 is the inline of a lib func so for short funcs you need no calls and so need not pass the registers on stack or register.
I do tests with the ixemul libc.a some time ago.
the sourcercode in libc.a is this
__attribute__((always_inline)) inline double hypot(double x,double y)
{
return sqrt(x*x+y*y);
}
this is the main source and create a ixemul prog (because only link with -ldebug)
#include
main(int argv,int argc)
{
double value;
value=hypot(argc,argv);
kprintf("%f\n",value);
}
I compile with -O1.
when i load the compiled exe in asm debugger it look as this.You see there is no call do and all is inline.
_main
+0000(10E33D22): LINK A5,#-$48
+0004(10E33D26): MOVEM.L D2-D3/A6,-(A7)
+0008(10E33D2A): BSR.L ___main ;10E340
+000E(10E33D30): FMOVE.L $C(A5),FP0
+0014(10E33D36): FMOVE.L 8(A5),FP1
+001A(10E33D3C): FMUL.X FP0,FP0
+001E(10E33D40): FMUL.X FP1,FP1
+0022(10E33D44): FADD.X FP1,FP0
+0026(10E33D48): FSQRT.X FP0
+002A(10E33D4C): FMOVE.D FP0,-(A7)
+002E(10E33D50): PEA _moncontrol+4(PC) ;10E33C84
+0032(10E33D54): BSR.L _kprintf ;10E33F74
How does that work exactly? If you have a function call to external function (and you don't use LTO), how can it replace the jump to the subroutine with other code?
If you mean you have to introduce all the inline functions in the headers then this is absolutely nothing new over gcc 2.x.
-
curios X86 have few register, better is maybe for RISC or use PPC always regparm now ?
I remember only warpup and powerup time, with GCC 2.xx.Here i see the parameter are put on stack.
IIRC both use System V ABI (http://refspecs.freestandards.org/elf/elfspec_ppc.pdf), although WarpUP breaks it by having the applications reuse r2. There's a fixed system on how the parameters are passed. See 3-18 Parameter Passing.
-
I know what LTO does. It wasn't included in gcc3.
According to documentation (http://gcc.gnu.org/wiki/LinkTimeOptimization#Requirements) you don't.
How does that work exactly? If you have a function call to external function (and you don't use LTO), how can it replace the jump to the subroutine with other code?
If you mean you have to introduce all the inline functions in the headers then this is absolutely nothing new over gcc 2.x.
I look now on the -S output gcc produce and ups i see wy it work, the math.h include the math-68881.h which contain this func
hypot (_CONST double x, _CONST double y)
{
return sqrt (x*x + y*y);
}
So i need play with the new LTO feature and test the example when i compile with -m68060
I see also when i compile with -m68060 the libc func is not use, seem a buildin GCC func is used for that.The asm code look much diffrent to above statement and contain lots more instructions and bad division.maybe the old hypot code of ixemul is buggy, or this GCC code is bad and slow written.
maybe somebody with good C math func knowledge can say more
+0000(10FEF1A6): MOVE.L A5,-(A7)
+0002(10FEF1A8): MOVEA.L A7,A5
+0004(10FEF1AA): FMOVEM.X FP2-FP3,-(A7)
+0008(10FEF1AE): FDMOVE.D 8(A5),FP3
+000E(10FEF1B4): FDMOVE.D $10(A5),FP2
+0014(10FEF1BA): FDABS.X FP3,FP1
+0018(10FEF1BE): FDABS.X FP2,FP0
+001C(10FEF1C2): FDADD.X FP0,FP1
+0020(10FEF1C6): FBNE _hypot+$34 ;10FEF1DA
+0024(10FEF1CA): FMOVE.D FP1,-(A7)
+0028(10FEF1CE): MOVE.L (A7)+,D0
+002A(10FEF1D0): MOVE.L (A7)+,D1
+002C(10FEF1D2): FMOVEM.X (A7)+,FP2-FP3
+0030(10FEF1D6): UNLK A5
+0032(10FEF1D8): RTS
+0034(10FEF1DA): FDDIV.X FP1,FP3
+0038(10FEF1DE): FDDIV.X FP1,FP2
+003C(10FEF1E2): FDMUL.X FP3,FP3
+0040(10FEF1E6): FDMUL.X FP2,FP2
+0044(10FEF1EA): FDADD.X FP2,FP3
+0048(10FEF1EE): FDSQRT.X FP3,FP0
+004C(10FEF1F2): FDMUL.X FP0,FP1
+0050(10FEF1F6): FMOVE.D FP1,-(A7)
+0054(10FEF1FA): MOVE.L (A7)+,D0
+0056(10FEF1FC): MOVE.L (A7)+,D1
+0058(10FEF1FE): FMOVEM.X (A7)+,FP2-FP3
+005C(10FEF202): UNLK A5
+005E(10FEF204): RTS
-
That code looks like a dog's dinner, I can see no reason whatsoever for the fdiv / fabs operations. x*x is always positive for all real x anyway.
The inlined version further up is pretty much what I'd write. The only thing in the longer version that makes immediate sense is the test for the sum of the squares being zero and skipping the square root in that case. However, that's a pretty pointless optimisation in my mind. I know that x*x tends to zero quickly for small x, but in reality how often is it likely to occur that the sum is fully zero?
Incidentally, I thought returning a double in fp0 was legal under the existing ABI. What's with the d0/d1 return?
-
That code looks like a dog's dinner, I can see no reason whatsoever for the fdiv / fabs operations. x*x is always positive for all real x anyway.
The inlined version further up is pretty much what I'd write. The only thing in the longer version that makes immediate sense is the test for the sum of the squares being zero and skipping the square root in that case. However, that's a pretty pointless optimisation in my mind. I know that x*x tends to zero quickly for small x, but in reality how often is it likely to occur that the sum is fully zero?
Incidentally, I thought returning a double in fp0 was legal under the existing ABI. What's with the d0/d1 return?
the default of the compiler is that FPU return values are always in d0 and d1.the reason is in that way there can work software float.
The linux 68k elf GCC use the FPU for return, i can too switch it easy on(i have get answer in GCC ML what need change), but here must be sure that all libs are fpu version and all libs need recompile.
but when such a big step is do and all libs need make new, then better change AOS GCC that it use elf format.so its more easy to have newest binutils for this.
in elf can also work the LTO.
In aminet there is source code of a elf loader patch for loadseg powerup.I think this can easy use for any CPU, because elf segements contain only code, and address offset correction that have nothing to do with CPU Code.
so a patch for loadseg can then handle the elf format and execute it.
But if that give more speed in real world apps i dont think, and to see if a optimation is usefull its best to look on profiler what funtions cost most time and optimize them.
Here i find the func hypot in gcc source gcc/builtins.c
static tree
fold_builtin_hypot (location_t loc, tree fndecl,
tree arg0, tree arg1, tree type)
{
tree res, narg0, narg1;
if (!validate_arg (arg0, REAL_TYPE)
|| !validate_arg (arg1, REAL_TYPE))
return NULL_TREE;
/* Calculate the result when the argument is a constant. */
if ((res = do_mpfr_arg2 (arg0, arg1, type, mpfr_hypot)))
return res;
/* If either argument to hypot has a negate or abs, strip that off.
E.g. hypot(-x,fabs(y)) -> hypot(x,y). */
narg0 = fold_strip_sign_ops (arg0);
narg1 = fold_strip_sign_ops (arg1);
if (narg0 || narg1)
{
return build_call_expr_loc (loc, fndecl, 2, narg0 ? narg0 : arg0,
narg1 ? narg1 : arg1);
}
/* If either argument is zero, hypot is fabs of the other. */
if (real_zerop (arg0))
return fold_build1_loc (loc, ABS_EXPR, type, arg1);
else if (real_zerop (arg1))
return fold_build1_loc (loc, ABS_EXPR, type, arg0);
/* hypot(x,x) -> fabs(x)*sqrt(2). */
if (flag_unsafe_math_optimizations
&& operand_equal_p (arg0, arg1, OEP_PURE_SAME))
{
const REAL_VALUE_TYPE sqrt2_trunc
= real_value_truncate (TYPE_MODE (type), dconst_sqrt2 ());
return fold_build2_loc (loc, MULT_EXPR, type,
fold_build1_loc (loc, ABS_EXPR, type, arg0),
build_real (type, sqrt2_trunc));
}
return NULL_TREE;
}
-
the default of the compiler is that FPU return values are always in d0 and d1.the reason is in that way there can work software float.
The linux 68k elf GCC use the FPU for return, i can too switch it easy on(i have get answer in GCC ML what need change), but here must be sure that all libs are fpu version and all libs need recompile.
but when such a big step is do and all libs need make new, then better change AOS GCC that it use elf format.so its more easy to have newest binutils for this.
in elf can also work the LTO.
Well that makes absolutely no sense whatsoever.
Care to explain in simple terms why the binaries would need to be ELF all the sudden?
-
Well that makes absolutely no sense whatsoever.
Care to explain in simple terms why the binaries would need to be ELF all the sudden?
i think nobody add LTO support for a.out.see your link on docu.
sooner or later the old a.out(which amiga use) format in GCC is drop too.currently i have not build a new binutils for 68k because they have drop the a.out Format in binutils.but luckily the linker and assembler need not change, but its not possible with easy work to build new gprof gdb etc.
see also a.out
http://en.wikipedia.org/wiki/A.out
The a.out Format is move to elf.
So to make things more easy, or need important new gprof or gdb or assembler(for Coldfire instructions) or linker using elf on AOS is better.
but all have time, currently i miss not elf.
change is easy, but only problem is there need build linker libs new.
and when there is no big reason to do that, then no elf is need
-
i think nobody add LTO support for a.out.
sooner or later the old a.out(which amiga use) format in GCC is drop too.
Yeah fine, but why would it require that the final resulting executables be ELF, too?
-
Yeah fine, but why would it require that the final resulting executables be ELF, too?
i think a linker does only put code peaces together and when the code that GCC produce is in elf, then the resulting output need too in elf.the disadvantage that all the lib files need in elf is here too.thats also same as when use clib2 or newlib on OS4 or clib2 or ixemul on 68k.
and write a linker that create from the elf output the amiga output is i think lots work.
and the problem is also that there need special ports for gdb and binutil.
with the little work to support elf files in loadseg, you can use all upto data linux 68k-elf gcc/binutil stuff in future and you have no extra work in future.
-
Yeah fine, but why would it require that the final resulting executables be ELF, too?
as i guess right, mxing of files do not work well.i search for
linker a.out elf mix
and i find this thread
http://blog.gmane.org/gmane.comp.gnu.binutils/month=20080501/page=2
Seem Atari go too the elf way.
but there is also great news see, there are convert tools here in binutil (objcopy), that can convert existing libs into the elf Format.
so there need not old lib recompile, only convert to use on a elf linker.
-
Cool. I've been thinking of looking for a newer gcc version for 68k. I don't know that I need special Amiga tweaks for it, but I do need it for Linux not Cygwin. So I'll try your docs and make one for amd64 ubuntu host. (I run Linux in a virtual machine under Windows instead of Cygwin)
-
The C++ includes and libs can download from other link.
What other link?
-
did anyone ever get anywhere with this, anyone mange to build a working 68k exe using GCC 4.5.0?
Anyone know if AmiDevCPP is ever going to be udpated to include GCC v4.5.0 support?
And finally is GCC 4.5.0 any good on 68k or should I stick with GCC v3.3 (AmiDevCPP)?
Thanx