[uClinux-dev] 68K GNU Compiler

[Michael Schnell]

Hi Experts,

This is rather off-topic, but I don't know where else I might find
experts on this.

I do development for the Innovasic FIDO processor, which is an 68 K
"CPU32" architecture, in fact a kind of upgrade tho the ubiquitously
used 68332 chip.

The Eclipse based IDE called "Sourcery" comes with a GNU compiler that
is built to work in FIDO-mode by default, but it also can be set to
compile for other chips (e.g. 68332, here it does not support the two
assembler instructions that are new with FIDO (e.g. "sleep").

Now I found that the code Generator seems to be rather bad. It generates
rather nasty code using a much higher count of instructions than
necessary, avoiding the more "CISK-specific" instruction in the CPU32
instruction set (such as moving a value from memory to memory, setting a
bit in a memory-cell, ...)

My very old MRI compiler for the 332 is a lot better on that behalf.

Is there any chance to find a more decent 68 K GNU C compiler ?

Thanks a lot,
-Michael

[Greg Ungerer]

Hi Michael,

Post by Michael Schnell
This is rather off-topic, but I don't know where else I might find
experts on this.
I do development for the Innovasic FIDO processor, which is an 68 K
"CPU32" architecture, in fact a kind of upgrade tho the ubiquitously
used 68332 chip.
The Eclipse based IDE called "Sourcery" comes with a GNU compiler that
is built to work in FIDO-mode by default, but it also can be set to
compile for other chips (e.g. 68332, here it does not support the two
assembler instructions that are new with FIDO (e.g. "sleep").

Do you know what version of gcc it uses?

Post by Michael Schnell
Now I found that the code Generator seems to be rather bad. It generates
rather nasty code using a much higher count of instructions than
necessary, avoiding the more "CISK-specific" instruction in the CPU32
instruction set (such as moving a value from memory to memory, setting a
bit in a memory-cell, ...)
My very old MRI compiler for the 332 is a lot better on that behalf.
Is there any chance to find a more decent 68 K GNU C compiler ?

Have you considered compiling your own?

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg at snapgear.com
SnapGear Group, McAfee PHONE: [phone]
8 Gardner Close FAX: [phone]
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com

[Luis Alves]

Hi,

Some time ago I was able to build my own non-working gcc toolchain for
the 68000 but in the end, after exchanging some mails I've found out
that support for the 68000 core was 'removed' since gcc >= 4.3
(I think Greg might remember this discussion)

I've filled up a bug report (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386)

I Don't know if the same was done for the CPU32 core but you better
find out before waiting time like I did.

At the moment I'm still using gcc 4.2.x

Regards,
Luis

Post by Greg Ungerer
Hi Michael,

Post by Michael Schnell
This is rather off-topic, but I don't know where else I might find
experts on this.
I do development for the Innovasic FIDO processor, which is an 68 K
"CPU32" architecture, in fact a kind of upgrade tho the ubiquitously
used 68332 chip.
The Eclipse based IDE called "Sourcery" comes with a GNU compiler that
is built to work in FIDO-mode by default, but it also can be set to
compile for other chips (e.g. 68332, here it does not support the two
assembler instructions that are new with FIDO (e.g. "sleep").

Do you know what version of gcc it uses?

Post by Michael Schnell
Now I found that the code Generator seems to be rather bad. It generates
rather nasty code using a much higher count of instructions than
necessary, avoiding the more "CISK-specific" instruction in the CPU32
instruction set (such as moving a value from memory to memory, setting a
bit in a memory-cell, ...)
My very old MRI compiler for the 332 is a lot better on that behalf.
Is there any chance to find a more decent 68 K GNU C compiler ?

Have you considered compiling your own?
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg at snapgear.com
SnapGear Group, McAfee PHONE: [phone]
8 Gardner Close FAX: [phone]
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/options/uclinux-dev

[Michael Schnell]

Post by Luis Alves
At the moment I'm still using gcc 4.2.x

In fact I have been provided with a 4.4.x version.

So I am slightly better off.

-Michael

[Michael Schnell]

Post by Luis Alves
At the moment I'm still using gcc 4.2.x

I would be thankful If you could check whether in your projects, gcc
creates code that sets ad checks bits in memory and does memory/memory
operations when appropriate.

I feel
volatile int xx, xy; xx |= 0x80; yx |= 0x0x80000000;

should create
BSET 7, xx+3 and BSET 7, xy



and
if (xy & 0x4000)

should create BTST 6, xy+2




and xy=xx

should create MOVE.L xx, xy



-Michael

[Greg Ungerer]

Hi Michael,

Post by Michael Schnell

Post by Luis Alves
At the moment I'm still using gcc 4.2.x

I would be thankful If you could check whether in your projects, gcc
creates code that sets ad checks bits in memory and does memory/memory
operations when appropriate.
I feel
volatile int xx, xy; xx |= 0x80; yx |= 0x0x80000000;
should create
BSET 7, xx+3 and BSET 7, xy
and
if (xy & 0x4000)
should create BTST 6, xy+2
and xy=xx
should create MOVE.L xx, xy

Heres one result. I am using a gcc-4.5.1 based toolchain. This code:

foo(void)
{
volatile int xx, xy;
xx |= 0x80;
xy |= 0x80000000;
if (xy & 0x4000)
xx = xy;
}

Compiled with this command line:

m68k-linux-gcc -mcpu32 -O2 -c foo.c

Produced this code:

00000000 <foo>:
0: 4e56 fff8 linkw %fp,#-8
4: 202e fffc movel %fp@(-4),%d0
8: 727f moveq #127,%d1
a: 4601 notb %d1
c: 8081 orl %d1,%d0
e: 2d40 fffc movel %d0,%fp@(-4)
12: 202e fff8 movel %fp@(-8),%d0
16: 08c0 001f bset #31,%d0
1a: 2d40 fff8 movel %d0,%fp@(-8)
1e: 202e fff8 movel %fp@(-8),%d0
22: 0800 000e btst #14,%d0
26: 6708 beqs 30 <foo+0x30>
28: 202e fff8 movel %fp@(-8),%d0
2c: 2d40 fffc movel %d0,%fp@(-4)
30: 4e5e unlk %fp
32: 4e75 rts

Regards
Greg



------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg at snapgear.com
SnapGear Group, McAfee PHONE: [phone]
8 Gardner Close, FAX: [phone]
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com

[Luis Alves]

Hi Michael,

Here is the result (gcc version is 4.2.4):

C test code used:

volatile int xx, xy;
volatile int yy, yx;
volatile int zz;

int main(void)
{
xx |= 0x80;
xy |= 0x80000000;

if (zz & 0x4000)
yy=yx;

return 0;
}

-------------------------------------

Resulting assembled code (using optimization flag -O2):

[...]
main:
link.w %fp,#0
move.l xx,%d0
moveq #127,%d1
not.b %d1
or.l %d1,%d0
move.l %d0,xx
move.l xy,%d0
bset #31,%d0
move.l %d0,xy
move.l zz,%d0
btst #14,%d0
jbeq .L2
move.l yx,%d0
move.l %d0,yy
.L2:
clr.l %d0
unlk %fp
rts
[...]


Since the volatile tells exactly that you want to use registers during
the manipulation of those variables, so I'm not surprised that it
doesn't change memory contents directly.


If I remove the volatile from the variable declaration, I have the
following assembly:

[...]
main:
link.w %fp,#0
or.w #128,xx+2
bset #7,xy
btst #6,zz+2
jbeq .L2
move.l yx,yy
.L2:
clr.l %d0
unlk %fp
rts
[...]


Which is what you were expecting (although it is using an OR instead
of a BSET in the first one).

Regards,
Luis

Post by Luis Alves
At the moment I'm still using gcc 4.2.x

I would be thankful If you could check whether in your projects, gcc creates
code that sets ad checks bits in memory and does memory/memory operations
when appropriate.
I feel
volatile int xx, xy; xx |= 0x80; yx |= 0x0x80000000;
should create
BSET 7, xx+3 and BSET 7, xy
and
if (xy & 0x4000)
should create BTST 6, xy+2
and xy=xx
should create MOVE.L xx, xy
-Michael
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/options/uclinux-dev

[Michael Schnell]

Post by Luis Alves
Since the volatile tells exactly that you want to use registers during
the manipulation of those variables, so I'm not surprised that it
doesn't change memory contents directly.

Ooops.

AFAIK, "volatile" means something like:
"this memory location is monitored or modified by another thread or by
hardware and thus any write and read needs to be done just as the c code
denotes and no read or write access is allowed to be be optimized away".

But maybe I am wrong here and in fact the idiot is myself and not the
compiler :-[ .

I'll check this out with my compiler version.

Thanks a lot !
-Michael

[Luis Alves]

Post by Michael Schnell

Post by Luis Alves
Since the volatile tells exactly that you want to use registers during
the manipulation of those variables, so I'm not surprised that it
doesn't change memory contents directly.

Ooops.
"this memory location is monitored or modified by another thread or by
hardware and thus any write and read needs to be done just as the c code
denotes and no read or write access is allowed to be be optimized away".

Sorry, you are right... I made some confusion with that.

Post by Michael Schnell
But maybe I am wrong here and in fact the idiot is myself and not the
compiler :-[ .
I'll check this out with my compiler version.
Thanks a lot !
-Michael
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/options/uclinux-dev

[Greg Ungerer]

Post by Michael Schnell

Post by Luis Alves
Since the volatile tells exactly that you want to use registers during
the manipulation of those variables, so I'm not surprised that it
doesn't change memory contents directly.

Ooops.
"this memory location is monitored or modified by another thread or by
hardware and thus any write and read needs to be done just as the c code
denotes and no read or write access is allowed to be be optimized away".

The compiler is still free to read into a register, work on the value
and then write it back. As long as the read and the write do still
occur.

If you are looking for atomic access then you need to do a little
more magic. Look at the Linux kernels atomic access functions for
example (linux/arch/m68k/include/asm/atomic.h in recent linux
kernels).

Regards
Greg

[Michael Schnell]

Post by Greg Ungerer
The compiler is still free to read into a register, work on the value
and then write it back. As long as the read and the write do still
occur.

Yep I do know this. Using volatile I just wanted to ensure that in fact
the memory cell is accessed. But in fact maybe the compiler really with
"volatile" generates less optimized code then without, even if manually
optimizing would lead to identical code.

I suppose, for testing, I should do a non volatile global variable so
that same needs to be left in a defined state when exiting the function.

Post by Greg Ungerer
If you are looking for atomic access then you need to do a little
more magic.

I do know this. For ensuring atomic operation you do need to use
(inline) ASM (macros).

But this is a different matter. Here I wanted to verify that the
compiler creates good code in the said cases (using memory in a not
explicitly volatile way).


thanks,
-Michael

[Michael Schnell]

Post by Luis Alves
Since the volatile tells exactly that you want to use registers during
the manipulation of those variables, so I'm not surprised that it
doesn't change memory contents directly.

Sorry for being vague and providing invalid code for the example.

I did not intend to define the volatile variables within the function
(thus on the stack) but outside (as global memory based variables).

-Michael

[Luis Alves]

Post by Michael Schnell

Post by Luis Alves
Since the volatile tells exactly that you want to use registers during
the manipulation of those variables, so I'm not surprised that it
doesn't change memory contents directly.

Sorry for being vague and providing invalid code for the example.
I did not intend to define the volatile variables within the function (thus
on the stack) but outside (as global memory based variables).

In my test code, I've defined them as global variables.
Regards

Post by Michael Schnell
-Michael
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/options/uclinux-dev

[Michael Schnell]

You are right.

My compiler also produces this absolutely decent code when not
specifying the variables as "volatile".

With "volatile" the code is a lot worse, I don't understand this, as the
"normal" code not only fulfills what is necessary to volatile but even
is "thread-atomic", as a thread switch does not do an interrupt within a
single instruction, not even with the Fido that provides _hardware_ threads.

Thanks a lot for discussing this with me.

-Michael

Post by Greg Ungerer
Hi Michael,
int xx, xy;
int yy, yx;
int zz;
int main(void)
{
xx |= 0x80;
xy |= 0x80000000;
if (zz & 0x4000)
yy=yx;
return 0;
}
[...]
link.w %fp,#0
or.w #128,xx+2
bset #7,xy
btst #6,zz+2
jbeq .L2
move.l yx,yy
clr.l %d0
unlk %fp
rts
[...]

[Michael Schnell]

Post by Michael Schnell
With "volatile" the code is a lot worse, I don't understand this, as
the "normal" code not only fulfills what is necessary to volatile ...

In fact the compiler might be right that "volatile" also includes
reading and writing all bytes of a variable with any access (as the
hardware might derive a trigger from same <e.g. when reading or writing
a hardware FiFo> ). Thus in-memory bit instructions, that only access a
single byte might be not appropriate for volatile int variables.

But nonetheless it's not a good idea of the compiler to avoid a
memory->memory move instruction for volatiles.

-Michael

[Michael Schnell]

Post by Greg Ungerer
Do you know what version of gcc it uses?

Thanks a lot for answering !

fido-none-elf-gcc.exe --version
fido-none-elf-gcc.exe (Sourcery G++ 4.4-186) 4.4.1 Copyright (C) 2009
Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

Post by Greg Ungerer
Have you considered compiling your own?

Considered: Of course :-) .

But I have no idea how to do this (in fact, on top of this I need the
Windows (CygWin) version) and moreover I don't know about the chances
that using a newer version (I understand that the current stable gcc is
somewhat like 4.6.x) could improve the situation - supposedly 68 K is
not on the top of the to-do list of FSF - , or If I would need to
introduce improvements myself (which I don't really dare to consider) .

-Michael

[Lennart Sorensen]

Post by Michael Schnell

Post by Greg Ungerer
Do you know what version of gcc it uses?

Thanks a lot for answering !
fido-none-elf-gcc.exe --version
fido-none-elf-gcc.exe (Sourcery G++ 4.4-186) 4.4.1 Copyright (C)
2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There
is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

Post by Greg Ungerer
Have you considered compiling your own?

Considered: Of course :-) .
But I have no idea how to do this (in fact, on top of this I need
the Windows (CygWin) version) and moreover I don't know about the
chances that using a newer version (I understand that the current
stable gcc is somewhat like 4.6.x) could improve the situation -
supposedly 68 K is not on the top of the to-do list of FSF - , or If
I would need to introduce improvements myself (which I don't really
dare to consider) .

I found gcc 4.3 was a great improvement over older versions for m68k
(coldfire specificly). Much better optimization and handling of larger
code sizes.

We haven't bothered to move past 4.3.3 for coldfire yet although at some
point we probably will.

[Michael Schnell]

Post by Lennart Sorensen
I found gcc 4.3 was a great improvement over older versions for m68k
(coldfire specificly). Much better optimization and handling of larger
code sizes. We haven't bothered to move past 4.3.3 for coldfire yet
although at some point we probably will.

I have no decent knowledge about Coldfire. I understand that Coldfire is
a kind of RISK and has different ASM code, only providing that any 68K
ASM instruction can rather easily translated into one or multiple
Coldfire ASM codes. So a C compiler might optimize cold for Coldfire
into a completely different instruction sequence than when optimizing
for CPU32.

-Michael

[Lennart Sorensen]

Post by Michael Schnell
I have no decent knowledge about Coldfire. I understand that
Coldfire is a kind of RISK and has different ASM code, only
providing that any 68K ASM instruction can rather easily translated
into one or multiple Coldfire ASM codes. So a C compiler might
optimize cold for Coldfire into a completely different instruction
sequence than when optimizing for CPU32.

My understanding is that the coldfire is still m68k, but has dropped
BCD support as well as some addressing modes from the instructions.
So it is partially object compatible as long as the code doesn't use
any of the removed features.

So it is quite similar but not the same.

According to freescale most coldfire object code will execute on the m68k
chips since the coldfire instruction set is pretty much just a subset
of the m68k. So if the compiler can generate code for the coldfire,
then that code ought to work fine on the m68k, although it could perhaps
have made it slightly more efficient by using some of the instructions
that are missing on the coldfire.

[Michael Schnell]

Post by Lennart Sorensen
My understanding is that the coldfire is still m68k, but has dropped
BCD support as well as some addressing modes from the instructions.

Yep. I suppose the addressing mode restriction might in fact be the
problem I see.

The examples I observed were setting bits in memory (hardware-addressing
mode: read-modify write a memory cell in a single instruction) and
moving a value from memory to memory (hardware-addressing mode:
read-modify write two memory cells in a single instruction). Both access
memory twice in a single instruction. Exactly this might be optimized
out when moving from 68K instruction set to Coldfire instruction set in
order to reduce the processor hardware complexity.

The FIDO processor I use does provide these addressing modes. But in
fact, Innovasic does not provide a list of cycle counts for the
instructions. So maybe the compiler even is right not to use these
instructions because they use more cycles than the combination it produces.

Post by Lennart Sorensen
So it is partially object compatible as long as the code doesn't use
any of the removed features.

I don't see why a decent (not Coldfire aware) 68K-compiler should not
extensively use these features to create highly optimized code.

Post by Lennart Sorensen
According to freescale most coldfire object code will execute on the m68k
chips since the coldfire instruction set is pretty much just a subset
of the m68k.

Yep. but a "decent" 68 K compiler) will create more compact and faster
code for e.g. CPU32. Exactly this is the issue I intended to discuss.
My impression is, that the compiler I have, in fact produces Coldfire
code and not CPU32 code (that might be more appropriate for FIDO)

Post by Lennart Sorensen
So if the compiler can generate code for the coldfire,
then that code ought to work fine on the m68k, although it could perhaps
have made it slightly more efficient by using some of the instructions
that are missing on the coldfire.

When I - using the "68332" documentation - compare the code my GNU
compiler generates, against that which I think would be more optimized
(and that to some extent is generated by my 15 year old MRI compiler)
the GNU code is worse by a factor of two to four regarding code size and
cycle count. Of course this is only true for these examples. With
"normal" calculation that issue does not show dramatically, as most work
is done within registers (thus "RISC-friendly").

-Michael

[Lennart Sorensen]

Post by Michael Schnell
Yep. I suppose the addressing mode restriction might in fact be the
problem I see.
The examples I observed were setting bits in memory
(hardware-addressing mode: read-modify write a memory cell in a
single instruction) and moving a value from memory to memory
(hardware-addressing mode: read-modify write two memory cells in a
single instruction). Both access memory twice in a single
instruction. Exactly this might be optimized out when moving from
68K instruction set to Coldfire instruction set in order to reduce
the processor hardware complexity.
The FIDO processor I use does provide these addressing modes. But in
fact, Innovasic does not provide a list of cycle counts for the
instructions. So maybe the compiler even is right not to use these
instructions because they use more cycles than the combination it produces.

I wonder where you could get cycle counts for each instruction.
I remember seeing them years ago for 8085 and such, but no idea of
freescale provides them.

Post by Michael Schnell
I don't see why a decent (not Coldfire aware) 68K-compiler should
not extensively use these features to create highly optimized code.

Well if you can find a decent compiler it ought to do that.

Post by Michael Schnell
Yep. but a "decent" 68 K compiler) will create more compact and
faster code for e.g. CPU32. Exactly this is the issue I intended to
discuss. My impression is, that the compiler I have, in fact
produces Coldfire code and not CPU32 code (that might be more
appropriate for FIDO)

Seems quite likely.

Post by Michael Schnell
When I - using the "68332" documentation - compare the code my GNU
compiler generates, against that which I think would be more
optimized (and that to some extent is generated by my 15 year old
MRI compiler) the GNU code is worse by a factor of two to four
regarding code size and cycle count. Of course this is only true for
these examples. With "normal" calculation that issue does not show
dramatically, as most work is done within registers (thus
"RISC-friendly").

gcc being a bad compiler is hardly surprising. One of my coworkers
complained that he was looking as some disassembled powerpc object code
in a debugger and even without much knowledge of powerpc it was obvious
that there were things that would have been trivial to optimize which
had not been optimized.

I do hope clang+llvm turns out to be a better compiler soon.

gcc has a vast list of supported architectures, but it sure isn't a
great compiler for any of them. It is just so universally available.

[Gavin Lambert]

Post by Lennart Sorensen
I wonder where you could get cycle counts for each instruction.
I remember seeing them years ago for 8085 and such, but no idea of
freescale provides them.

I still have something that uses the 68332 (the original CPU32, I believe);
for that there are detailed instruction timings in section 8 of the CPU32RM
manual. (It's a little complex as there is variable-length pipelining per
instruction and addressing mode.)

Not sure if these are applicable to the FIDO as well, but there will
probably at least be similarities.

[Michael Schnell]

Post by Gavin Lambert
Not sure if these are applicable to the FIDO as well, but there will
probably at least be similarities.

Innovasic claims that for most instructions the cycle count is equal or
lower. But there might be some exceptions. But they don't provide a list
or a guarantee.

-Michael

[Greg Ungerer]

Post by Lennart Sorensen

Post by Michael Schnell
Yep. I suppose the addressing mode restriction might in fact be the
problem I see.
The examples I observed were setting bits in memory
(hardware-addressing mode: read-modify write a memory cell in a
single instruction) and moving a value from memory to memory
(hardware-addressing mode: read-modify write two memory cells in a
single instruction). Both access memory twice in a single
instruction. Exactly this might be optimized out when moving from
68K instruction set to Coldfire instruction set in order to reduce
the processor hardware complexity.
The FIDO processor I use does provide these addressing modes. But in
fact, Innovasic does not provide a list of cycle counts for the
instructions. So maybe the compiler even is right not to use these
instructions because they use more cycles than the combination it produces.

I wonder where you could get cycle counts for each instruction.
I remember seeing them years ago for 8085 and such, but no idea of
freescale provides them.

Most of the ColdFire SoC Reference Manuals have a section titled
"Instruction Execution Timing", which gives a pretty good run down
on instruction timing. Probably not terribly useful for any of
the older 68k class CPU's though.

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg at snapgear.com
SnapGear Group, McAfee PHONE: [phone]
8 Gardner Close FAX: [phone]
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com

[Michael Schnell]

I wonder where you could get cycle counts for each instruction. I
remember seeing them years ago for 8085 and such, but no idea of
freescale provides them.

I remember that the 68332 documentation does provide cycle count. the
calculation is complicated, as it depends on the count of cycles
necessary to access the different memory areas that are accessed.

Post by Michael Schnell
I don't see why a decent (not Coldfire aware) 68K-compiler should
not extensively use these features to create highly optimized code.

Well if you can find a decent compiler it ought to do that.

In fact I found that the compiler does create decent code for
non-volatile variables but when specifying volatile the code gets a lot
worse, even though the normal code already fulfills all specs necessary
for volatile variables.

-Michael

[Lennart Sorensen]

Post by Michael Schnell
I remember that the 68332 documentation does provide cycle count.
the calculation is complicated, as it depends on the count of cycles
necessary to access the different memory areas that are accessed.
In fact I found that the compiler does create decent code for
non-volatile variables but when specifying volatile the code gets a
lot worse, even though the normal code already fulfills all specs
necessary for volatile variables.

There does seem to be some interesting bugs related to volatile:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33068

Also a claim that newer gcc's generate worse and worse code for m68k:

http://www.natami.net/knowledge.php?b=3&note=8

It sounds like gcc 4.3, 4.4 and 4.5 have been improving again with
each release. Apparently 4.2 was the worst one to use.