Comments on: GCC makes a mess http://hardwarebug.org/2009/05/13/gcc-makes-a-mess/ Everything is broken Mon, 30 Aug 2010 09:33:38 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Michael Kostylev http://hardwarebug.org/2009/05/13/gcc-makes-a-mess/comment-page-1/#comment-483 Michael Kostylev Tue, 01 Dec 2009 17:22:47 +0000 http://hardwarebug.org/?p=131#comment-483 ColdFire (-mcpu=5475) is somehow supported, r20684 passes 308/310. ColdFire (-mcpu=5475) is somehow supported, r20684 passes 308/310.

]]> By: ami_stuff http://hardwarebug.org/2009/05/13/gcc-makes-a-mess/comment-page-1/#comment-71 ami_stuff Sun, 07 Jun 2009 12:42:20 +0000 http://hardwarebug.org/?p=131#comment-71 Mans, could you try to create code for 68060? This way we will know if this slowdown is because of slow GCC asm generated code or maybe it's normal without hardware 32x32->64 and there is nothing what can be done without re-design of the mpegaudio decoder? Thanks Mans, could you try to create code for 68060? This way we will know if this slowdown is because of slow GCC asm generated code or maybe it’s normal without hardware 32×32->64 and there is nothing what can be done without re-design of the mpegaudio decoder? Thanks

]]> By: Bernd_afa http://hardwarebug.org/2009/05/13/gcc-makes-a-mess/comment-page-1/#comment-63 Bernd_afa Thu, 21 May 2009 10:53:06 +0000 http://hardwarebug.org/?p=131#comment-63 I test this -03 -m68020 -m68040 same result int64_t MULH(int a, int b) { return ((int64_t)(a) * (int64_t)(b))>>32; } main(int argc, char *argv[]) { printf ("%ld\n",MULH(argc,(long)argv)); } the code for 68060 is very inefficent, because there is no asm macro in longlong.h the command MULS.L D4,D2:D6 is also not support on the UAE JIT and is slow execute by interpreter. i think in gcc longlong.h is miss code for 68060. I see coldfire code, but this code is too so complex, is a 32 bit *32 bit -> 64 bit result not easier possible ? gcc 3.4.0 MOVE.L 8(A5),D7 MOVE.L $C(A5),D4 BSR.L ___main ; MOVE.L D7,D6 MULS.L D4,D2:D6 MOVE.L D2,-(A7) SMI D0 EXTB.L D0 MOVE.L D0,-(A7) PEA _MAC64+$2E(PC) LEA _printf,A3 ; gcc 4.3.2 MOVE.L $C(A5),D1 MULS.L 8(A5),D0:D1 MOVE.L D0,-(A7) SMI D2 EXTB.L D2 MOVE.L D2,-(A7) PEA _time_delay+$F8(PC) LEA _printf,A3 ;10F94 gcc 4.4.0 MOVE.L 8(A5),D2 MOVE.L $C(A5),D3 JSR ___main ;10FD50 MOVE.L D3,D1 MULS.L D2,D0:D1 MOVE.L D0,-(A7) SMI D2 EXTB.L D2 MOVE.L D2,-(A7) PEA _time_delay+$FA(PC) LEA _printf,A3 ;10FD53 now with -m68060 MOVE.L 8(A5),-(A7) SMI D0 EXTB.L D0 MOVE.L D0,-(A7) MOVE.L $C(A5),-(A7) SMI D2 EXTB.L D2 MOVE.L D2,-(A7) JSR ___muldi3 ;110504 LEA $10(A7),A7 MOVE.L D0,-(A7) SMI D2 EXTB.L D2 MOVE.L D2,-(A7) PEA _time_delay+$FA(PC) LEA _printf,A3 ;110508 JSR (A3) ...... ___muldi3 110504A8: MOVE.L A5,-(A7) 110504AA: MOVEA.L A7,A5 110504AC: MOVEM.L D2-D7/A2,-(A7) 110504B0: MOVE.L $C(A5),D5 110504B4: MOVE.L $14(A5),D6 110504B8: MOVEA.L 8(A5),A2 110504BC: MOVE.L $10(A5),D7 110504C0: MOVE.L D5,D0 110504C2: MOVE.L D6,D1 110504C4: MOVE.L D0,D2 110504C6: SWAP D0 110504C8: MOVE.L D1,D3 110504CA: SWAP D1 110504CC: MOVE D2,D4 110504CE: MULU D3,D4 110504D0: MULU D1,D2 110504D2: MULU D0,D3 110504D4: MULU D0,D1 110504D6: MOVE.L D4,D0 110504D8: EOR D0,D0 110504DA: SWAP D0 110504DC: ADD.L D0,D2 110504DE: ADD.L D3,D2 110504E0: BCC.S ___muldi3+$40 ;110504E8 110504E2: ADDI.L #$10000,D1 110504E8: SWAP D2 110504EA: MOVEQ #0,D0 110504EC: MOVE D2,D0 110504EE: MOVE D4,D2 110504F0: MOVEA.L D2,A1 110504F2: ADD.L D1,D0 110504F4: MOVEA.L D0,A0 110504F6: MOVE.L A1,D1 110504F8: MULS.L D7,D5 110504FC: MOVE.L A2,D2 110504FE: MULS.L D2,D6 11050502: ADD.L D6,D5 11050504: ADD.L A0,D5 11050506: MOVE.L D5,D0 11050508: MOVEM.L (A7)+,D2-D7/A2 1105050C: UNLK A5 1105050E: RTS I test this
-03 -m68020
-m68040 same result

int64_t MULH(int a, int b)
{
return ((int64_t)(a) * (int64_t)(b))>>32;
}

main(int argc, char *argv[])
{

printf (“%ld\n”,MULH(argc,(long)argv));
}

the code for 68060 is very inefficent, because there is no asm macro in longlong.h
the command MULS.L D4,D2:D6 is also not support on the UAE JIT and is slow execute by interpreter.

i think in gcc longlong.h is miss code for 68060.
I see coldfire code, but this code is too so complex, is a 32 bit *32 bit -> 64 bit result not easier possible ?

gcc 3.4.0
MOVE.L 8(A5),D7
MOVE.L $C(A5),D4
BSR.L ___main ;
MOVE.L D7,D6
MULS.L D4,D2:D6
MOVE.L D2,-(A7)
SMI D0
EXTB.L D0
MOVE.L D0,-(A7)
PEA _MAC64+$2E(PC)
LEA _printf,A3 ;

gcc 4.3.2

MOVE.L $C(A5),D1
MULS.L 8(A5),D0:D1
MOVE.L D0,-(A7)
SMI D2
EXTB.L D2
MOVE.L D2,-(A7)
PEA _time_delay+$F8(PC)
LEA _printf,A3 ;10F94

gcc 4.4.0

MOVE.L 8(A5),D2
MOVE.L $C(A5),D3
JSR ___main ;10FD50
MOVE.L D3,D1
MULS.L D2,D0:D1
MOVE.L D0,-(A7)
SMI D2
EXTB.L D2
MOVE.L D2,-(A7)
PEA _time_delay+$FA(PC)
LEA _printf,A3 ;10FD53

now with -m68060

MOVE.L 8(A5),-(A7)
SMI D0
EXTB.L D0
MOVE.L D0,-(A7)
MOVE.L $C(A5),-(A7)
SMI D2
EXTB.L D2
MOVE.L D2,-(A7)
JSR ___muldi3 ;110504
LEA $10(A7),A7
MOVE.L D0,-(A7)
SMI D2
EXTB.L D2
MOVE.L D2,-(A7)
PEA _time_delay+$FA(PC)
LEA _printf,A3 ;110508
JSR (A3)

……

___muldi3
110504A8: MOVE.L A5,-(A7)
110504AA: MOVEA.L A7,A5
110504AC: MOVEM.L D2-D7/A2,-(A7)
110504B0: MOVE.L $C(A5),D5
110504B4: MOVE.L $14(A5),D6
110504B8: MOVEA.L 8(A5),A2
110504BC: MOVE.L $10(A5),D7
110504C0: MOVE.L D5,D0
110504C2: MOVE.L D6,D1
110504C4: MOVE.L D0,D2
110504C6: SWAP D0
110504C8: MOVE.L D1,D3
110504CA: SWAP D1
110504CC: MOVE D2,D4
110504CE: MULU D3,D4
110504D0: MULU D1,D2
110504D2: MULU D0,D3
110504D4: MULU D0,D1
110504D6: MOVE.L D4,D0
110504D8: EOR D0,D0
110504DA: SWAP D0
110504DC: ADD.L D0,D2
110504DE: ADD.L D3,D2
110504E0: BCC.S ___muldi3+$40 ;110504E8
110504E2: ADDI.L #$10000,D1
110504E8: SWAP D2
110504EA: MOVEQ #0,D0
110504EC: MOVE D2,D0
110504EE: MOVE D4,D2
110504F0: MOVEA.L D2,A1
110504F2: ADD.L D1,D0
110504F4: MOVEA.L D0,A0
110504F6: MOVE.L A1,D1
110504F8: MULS.L D7,D5
110504FC: MOVE.L A2,D2
110504FE: MULS.L D2,D6
11050502: ADD.L D6,D5
11050504: ADD.L A0,D5
11050506: MOVE.L D5,D0
11050508: MOVEM.L (A7)+,D2-D7/A2
1105050C: UNLK A5
1105050E: RTS

]]> By: ami_stuff http://hardwarebug.org/2009/05/13/gcc-makes-a-mess/comment-page-1/#comment-62 ami_stuff Thu, 21 May 2009 01:30:06 +0000 http://hardwarebug.org/?p=131#comment-62 so for 68060 CPU libmad is the best choice so for 68060 CPU libmad is the best choice

]]> By: ami_stuff http://hardwarebug.org/2009/05/13/gcc-makes-a-mess/comment-page-1/#comment-61 ami_stuff Thu, 21 May 2009 01:27:14 +0000 http://hardwarebug.org/?p=131#comment-61 Bad News. This all speedup was because I compared 68060 build of FFmpeg with 68040 build. 68060 build needs to emulate "muls" instruction - here is a speedup. Also, 68040 build generates different wav file compared to 68060 build. When I compile with your MAC64 & MLS64 functions I get only 1 sec. speedup. MULH don't want to compile - statement 'mul.l (a6),d2:d1' ignored etc. Bad News. This all speedup was because I compared 68060 build of FFmpeg with 68040 build. 68060 build needs to emulate “muls” instruction – here is a speedup. Also, 68040 build generates different wav file compared to 68060 build.

When I compile with your MAC64 & MLS64 functions I get only 1 sec. speedup.

MULH don’t want to compile – statement ‘mul.l (a6),d2:d1′ ignored etc.

]]> By: Mans http://hardwarebug.org/2009/05/13/gcc-makes-a-mess/comment-page-1/#comment-60 Mans Wed, 20 May 2009 23:48:20 +0000 http://hardwarebug.org/?p=131#comment-60 Could you try disabling the asm functions one at a time and see which causes the discrepancy? Could you try disabling the asm functions one at a time and see which causes the discrepancy?

]]> By: ami_stuff http://hardwarebug.org/2009/05/13/gcc-makes-a-mess/comment-page-1/#comment-59 ami_stuff Wed, 20 May 2009 23:10:16 +0000 http://hardwarebug.org/?p=131#comment-59 I'm running it on WinUAE emulator. I hear no different, but "find dups" program don't recognize file decoded with standard FFmpeg and asm-optimized as identicial. I can decode some short file and send it to you to mail if you want, so you can analyze it. I’m running it on WinUAE emulator. I hear no different, but “find dups” program don’t recognize file decoded with standard FFmpeg and asm-optimized as identicial. I can decode some short file and send it to you to mail if you want, so you can analyze it.

]]> By: Mans http://hardwarebug.org/2009/05/13/gcc-makes-a-mess/comment-page-1/#comment-58 Mans Wed, 20 May 2009 23:05:44 +0000 http://hardwarebug.org/?p=131#comment-58 What hardware are you running this on? Can you confirm that the decoded output is correct, please? 68060 doesn't have the 32x32->64 multiply instruction, but I'm sure it's not too hard to beat gcc even without it. The floating point rounding functions are not used in speed-critical places so there is no need to optimise them. What hardware are you running this on? Can you confirm that the decoded output is correct, please?

68060 doesn’t have the 32×32->64 multiply instruction, but I’m sure it’s not too hard to beat gcc even without it.

The floating point rounding functions are not used in speed-critical places so there is no need to optimise them.

]]> By: ami_stuff http://hardwarebug.org/2009/05/13/gcc-makes-a-mess/comment-page-1/#comment-57 ami_stuff Wed, 20 May 2009 22:55:31 +0000 http://hardwarebug.org/?p=131#comment-57 It beats libmad by 1 sec. With more optimizations like asm llrint() it will be even faster. Is there a way to asm optimized code for 68060 build too? It beats libmad by 1 sec. With more optimizations like asm llrint() it will be even faster.

Is there a way to asm optimized code for 68060 build too?

]]> By: ami_stuff http://hardwarebug.org/2009/05/13/gcc-makes-a-mess/comment-page-1/#comment-56 ami_stuff Wed, 20 May 2009 22:50:56 +0000 http://hardwarebug.org/?p=131#comment-56 Holly shit! Only 29 sec. now! Holly shit! Only 29 sec. now!

]]>