Do you think it makes sense to post here some C-code snippes together with the ASM instruction compiled by GCC as examples on how GCC operates?

The examples could be used for brainstorming and to identify patterns in the behavior of GCC.

Cheers
Gunnar

Hi Gunnar,

however important I think the discussion here is, it is much more important to be done in the proper place, ie in the gcc bugtracker and gcc mailing lists. It's much more probable to be fixed there by the right persons, and even the Freescale/CodeSourcery guys are probably following these. Of course if you don't mind, it would be interesting to read these here as well :)

Regards

Konstantinos

I think the discussion is very relevant here :)

However I do think the compiler performance shouldn't be Gunnar's goal here. We're talking about mimicking a 68k processor on ColdFire for a specific application. At this point a 200MB/s bus bandwidth for read is about 3x more than he would expect from a 68060 with EDO SDRAM with a 60ns access time. Certain versions of the GCC compiler generate adequate - if not performance - code (later versions, seemingly, do not). We know CodeWarrior and DIAB and GreenHills do better. In the end, mimicking the m68k does not rely on the compiler but the technique used, of which - as he has very competantly explained in his project and elsewhere - could be one of 3 or 4 or 5 different ways (perhaps a QEMU/UAE style virtual machine, or an instruction trap mechanism as with the 68000 fpsp or 68040/68060.library mechanisms on AmigaOS, or something like ShapeShifter/Sheepshaver MacOS emulation on the Amiga, where 90% of the instructions are run native but important differences are emulated for the purpose of seperation of operating systems).

This is where the important work lies. Redefining the operation of GCC4 is a waste of time. You can code the emulator now, find the best method, and fix GCC later so that it enables compilation and linking of the best method with the least amount of manual hacking. But compiler reworks are the last resort - until, that is, you hit a compiler bug that refuses to generate working code or causes exceptions or doesn't even compile, THEN it is something worth fixing :)

_________________
Matt Sealey

I agree that the discussion is relevant about Gunnar's project and any details around it. My point was about GCC bugs that would get too technical. It's not that *shouldn't* be here, it's that they should be on GCC bugtracker *too*! :)

After all, for any project most bugs are found elsewhere rather than the bugtracker/mailing lists and then filed as bug reports upstream.

In any case, don't mind me, please continue, it was an interesting read anyway :)

Konstantinos

Hi Matt,
So far I have only measured 120 MB/sec read for the V4m.
You can find a comparison of 680x0 and V4m results here:
http://www.powerdeveloper.org/forums/vi ... 0621#10621

I hope this helps you.

One GCC example:

C-source Compile option: m68k-linux-gnu-gcc -mcpu=54455 -msoft-float -o example -Os -fomit-frame-pointer example.c
We use -Os to focus on compact code.

Generated code: Code length produced by GCC = 56 Byte
Length of workloop = 9 instructions , 38 Byte


Expected code: Expected code length = 30 Byte
Length of workloop = 6 instructions , 12 Byte



Issue 1:
Why does GCC not use the ConditionCodes already set by the 68k instruction but generates a unneeded test.l?

Issue 2:
Why does GCC not use the much more efficient (an)+ adressing mode but uses instead d(an) mode plus an extra add instrcution ?
The (Ad)+,(Am)+ instruction is 2 Bytes instead of 6 Bytes.
And (Ad)+,(Am)+ does not need the extra two instructions to increment the pointers.

Issue 3:
Assuming that GCC decided to increment a pointer manually.
Why does GCC use addil to increment a pointer?
LEA should be the better choice for this as its 2 bytes shorter than addi.l

Second example:

C-Code:
Generated output Generated code length = 46 Byte
Length of Workloop: 9 instructions, 32 byte


The expected result would be Expected code length = 28 Byte
Length of Workloop: 6 instructions, 12 byte


Issue 4:
We see again the unneeded TST instruction.

Issue 5:
The Compiler again uses a much bigger and slower addressing mode.

Issue 6:
The preload of the work value into register D1 is done inside the work loop. The should be done outside of the main workloop.

Issue 7:
The compiler decides to put the literal work value #1 into the work register D1. But its not always using this work register, one time it uses a literal move.l #1, and thereby unneeded increasing the code by 4 bytes.


Both GCC 4 examples have 9 instruction inside the workloop. Older GCC would solve the same task using a workloop of only 6 instructions.
Generelly the new GCC 4 code is bigger and a lot slower than before.

To help improve the Code generated by GCC for Coldfire/68K, I've filed the bugs 36133, 36134, 36135, and 36136 to the GCC-Compiler.

Hi Gunnar,

do you know by chance, if the gcc 3.4 code suffers of the same problems?