You need the patched binutil-2.14 which is in the toolchain:
... it's just a start.

Bebbo

Can we see some generated code?

For reference here is a small function strcpy.c

With amiga-gcc cross-compiler 3.4.0
The resulting strcpy.s
And with gcc-m68k (not for amiga) 5.4.0
Can we see the relevant strcpy.s from 6.x please?
Thanks.

I don't have libnix built yet but GCC 6.2.1 produces this:

This is not using the AT&T ABI so is not comparable to what alkis posted. What option did you use to get it to pass arguments in registers?

The code is flawed of course (as usual with GCC) and should probably be the following using register arguments as above with a0=dst a1=src (inlining would be better where possible).

Same as alkis.

Very strange that the AT&T (stack args) ABI would not be used, especially with the same options. The Amiga Geek Gadgets guys tried to introduce a more efficient ABI using registers in the unofficial Amiga GCC versions up to 3.4.0 (good idea but buggy in my experience as was the RTD support). The official GCC maintainers refused to consider anything but the AT&T ABI for the 68k, including customizable register arguments for functions, while they supported several ABIs for the x86/x86_64 for years (regparm and fastcall among a wide selection). No new ABI was introduced even for the ColdFire although the MOV3Q was introduced primarily for popping the arguments off the stack since RTD was removed (because RTD support was buggy in GCC?). I don't know if the failed support for the 68k/CF is because of incompetence or bias but probably some of both by the GCC developers and the 68k/CF developers.

Are you taking a stand that C compilers are flawed in the amiga? :)

Or...what code does your favorite amiga c compiler produces???

The code generation is flawed in comparison to what modern compilers are capable of.

Vbcc uses assembler inlines by default giving the following code for strcpy().

Beautiful! Perfect! Short sweet and inlined. However, if you compile the C code above you get the following.

Doh! Epic fail! Dr. Barthelmann and his vbcc compiler are capable of more but realistically, as I told Frank Wille, it is not going to happen without support for the 68k and Amiga. Who wants to waste time on a dead platform for a handful of people?

Wow, that's bad. I don't think even old compilers like SAS/C produce that kind of code. Just wow :rolleyes

I certainly know which compiler to avoid now. What a shame :(

It is embarrassing and frustrating. Vbcc can generate some of the best code and some of the worst. I don't know what happened here. It was generating better code in an earlier version. It is capable of using advanced instructions and addressing modes like move.b (a1)+,(a0)+ but then so is GCC. Maybe there is a fix already for some of the problems but more problems seem to creep back in with both vbcc and GCC. Too much complexity and not enough developers any more. Sad :sad.

At least that means SAS/C isn't useless ;)

Here's what SAS/C produces, for those who are interested.

Seems like the gcc-3.4.0 produces the most efficient code then, as it avoids saving/restoring a register to stack.

For code this trivial compilers should produce:
Or better:

Well, with

it unrolls it 8 times

I don't understand why the peephole optimiser doesn't convert
to moveb a0@,a1@ since d0 is dead after, but hey...

not that i understand much but for the sake of it, results of both aros68k compilers im currently using:

strcpy:
move.l 4(%sp),%d0 | dst, dst
move.l 8(%sp),%a1 | src, src
move.l %d0,%a0 | dst, ivtmp.11
.L2:
move.b (%a1)+,%d1 | MEM[base: src_8, offset: 4294967295B], _9
move.b %d1,(%a0)+ | _9, MEM[base: _14, offset: 0B]
jne .L2 |
rts
.size strcpy, .-strcpy
.ident "GCC: (GNU) 6.1.0"


strcpy:
move.l 4(%sp),%d0 | dst, dst
move.l 8(%sp),%a1 | src, ivtmp.9
move.l %d0,%a0 | dst, dst
.L2:
move.b (%a1)+,%d1 | MEM[base: D.779_19, offset: 0B], D.759
move.b %d1,(%a0)+ | D.759, MEM[base: dst_1, offset: 0B]
jne .L2 |
rts
.size strcpy, .-strcpy
.ident "GCC: (GNU) 4.6.4"

what is
for?

What is gained by unrolling one loop into four loops?

Duff's device is not cache friendly and offers no speed benefit in this case.

That's something, at least.

Yeah, that's pretty shitty and makes no sense.

D0 is the return value.

On 68020s and 68030s taken branches are 8 cycles, not taken byte branches are 4 cycles.

I expect it is generally better to inline strcpy() where it is called than unroll strcpy() after a costly push/bsr/rts/pop (assuming strings are not excessively long). This is what vbcc does with the assembler inlines.

That is not a peephole optimization. Further analysis outside of this code snippet is needed to conclude the optimization can be done (it is not guaranteed to be an equivalent replacement). Two instruction input peephole optimizations are aggressive too. Vasm only looks at one instruction max (but can output multiple instructions) and it is currently the best 68k peephole optimizing assembler.

@wawa
The aros68k GCC compiler is doing a good job here. It should be able to merge 2 lines inside the loop but overall good.

strcpy() returns a pointer to the destination. The return is rarely used because it is already available and doesn't change but that is how it is defined.

It is much more useful to return a pointer to the end of the string like stpcpy().

This came from SAS/C to BSD where it became part of POSIX but not C99 or C11.