Hi Holger, On Sat, Dec 24, 2022 at 10:34 AM Holger Lubitz <holger.lubitz@xxxxxxxxxxx> wrote: > On Thu, 2022-12-22 at 10:41 +0000, David Laight wrote: > > I wonder how much slower it is - m68k is likely to be microcoded > > and I don't think instruction timings are actually available. > > Not sure if these are in any way official, but > http://oldwww.nvg.ntnu.no/amiga/MC680x0_Sections/mc68030timing.HTML > > (There's also > http://oldwww.nvg.ntnu.no/amiga/MC680x0_Sections/mc68000timing.HTML > but that is probably only interesting to demo coders by now) Yes, instruction timings are available. Unlike for e.g. x86, there is only a very limited number of parts to consider. > > I believe some of the other m68k asm functions are also missing > > the "memory" 'clobber' and so could get mis-optimised. > > In which case would that happen? This function doesn't clobber memory > and its result does get used. If gcc mistakenly thinks the parameters > haven't changed and uses a previously cached result, wouldn't that > apply to a C function too? For a pure C inline function, the compiler knows exactly what it does. For an external C function, the compiler assumes all odds are off. For inline asm, the compiler doesn't know what happens with (the data pointed to by) the pointers, unless that's described in the constraints. We do have some inline asm that has "*ptr" in the constraints, but that applies to a single value, not to an array. And in case of strings, the size of the array is not known without looking for the zero-terminator. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
