New improved intuition.library version from the Kickstart 3.1

[matthey]

"Can we all get along?"

@Cosmos
I agree that there is a compiler problem in the AmigaOS and I too want to fix it. If the problem is compilers then we must improve the compilers. I agree that some developer's attitudes have been less than helpful but a sour and hostile attitude will only make it worse. I don't have a problem with you hacking abandoned software but you should be more respectful of those still developing because they are also fighting against obsolescence of the Amiga. Reverse engineering with micro-optimizations is not the way to further develop the Amiga. Losing the comments while reverse engineering is a major setback in development. Development decisions should not be made solely by one person because humans are too fallible. There are very experienced developers that know what they are doing and need to be listened to and respected. I am one of the developers that has responded to your e-mails and given you code yet I doubt that I am the "one" that gave you sources. You can't "evolve" the AmigaOS by yourself because not enough people will accept your work and methods.

@ThoR
So called "hackers" and "cycle counters" like Cosmos and I have found and (sometimes) reported several important bugs. At times you have been condescending and ignored anything below major algorithm changes. Ignoring the fact that your compiler is generating awful code greatly increases the chances that people like Cosmos and I are going to come along and optimize away half your code even if it only saves some memory. You could at least compile 68020 versions of AmigaOS modules as it takes very little time for these small modules. There is less compiler complexity for 68020 code which might just give better quality code and code optimized for a 16 bit 68000 CPU is not efficient on a 32 bit 68020+ CPU. AmigaOS started requiring a 68020+ and you are still compiling for a 68000. Do you compile your x86 codecs for a 8086? Compilers are made to optimize (and micro-optimize) but you have to choose the correct target. Amiga users still want an efficient AmigaOS today which allows them to continue to use low spec processors with minimal memory. Ignoring the users and possibly better compilers isn't going to help your cause either. Expecting the Amiga community or some rich suitor to come along and start paying you to continue to do what you want to do developing the AmigaOS probably isn't going to happen anytime either. I think you are willing to work for less than you are worth to do what you love to do though. The Amiga is in you just as much as Cosmos whether you are willing to admit it or not.

[matthey]

It is optimal it is inlined. Actually, any decent compiler will that do automatically for you if the size of the memory block to be copied is known at compile time, including a complete unrolling of the copy if the size is small enough, and probably fall back to a small inlined routine if it is not avoiding the per-call overhead then. At least this is what SAS/C does, and it's quite plausible that this is the best option.  

I'm not so sure that "most" compilers will optimize memcpy() for static cases. Most compilers will optimize to some extent small copies implied with '=' which are practically all static sizes. The C memcpy() function is generally optimized for small to medium sized copies and doesn't detect for small static sizes. I have never seen the SAS/C memcpy()  function inlined (and it is poor for the 68040 and awful for the 68060). Vbcc will use assembler inlines by default for memcpy() and the new unreleased version of vbcc has much improved 68000 and 68020 optimized assembler versions of memcpy(). Maybe GCC is smart enough to check for static cases when using memcpy(). Medium to large sized copies are best handled by exec/CopyMem() or exec/CopyMemQuick() if they are patched with CPU specific optimized versions. The new vbcc versions of memcpy() will likely outperform unpatched exec/CopyMem() and exec/CopyMemQuick() for all sizes on the 68040 and 68060. Using an '=' for copies is likely to be the fastest for tiny to small copy sizes with practically all compilers on all 68k processors though.

I'm not clear which programs actually use CopyMemQuick() anyhow - probably the FFS does in case the "Mask" does not fit the target of the memory buffer (i.e. the handling device is "broken" and cannot reach the memory indicated as buffer by the caller). In any event, the impact CopyMem and friends has on performance of your average AmigaOs installation should be quite irrelevant. It would be interesting to see if someone could just set a breakpoint there and measure how often it is used. I suspend "not so often".

CopyMemQuick() is rarely use by the AmigaOS or any other programs (Scout is one of the few programs). CopyMem() is used extensively by the AmigaOS as well as many programs. The AmigaOS uses many tiny copies (<16 bytes) and it looks like some may be static. CopyMem() may have been used for tiny and small copies because the alignment is unknown and the source originally was for a 68000 where it could crash. It's fastest for tiny sizes to inline unaligned copies on the 68020+. I made a Snoopy (like SnoopDOS) script for CopyMem() and CopyMemQuick() to determine how often, which alignments, which sizes and which programs use these functions. The Snoopy script is available in this archive:

http://aminet.net/util/boot/CopyMem.lha

The script records the uses to memory. Be prepared to break the script after a few seconds from starting or you will run out of memory in less than a minute on the average Amiga. I wouldn't call that kind of use "not so often".

[matthey]

SAS/C certainly inlines memcpy() if you tell it to, but it will not "unroll" it if this is what you mean. I believe it expands into a simple move.b (a0)+,(a1)+ loop, likely non-ideal, but good enough for most cases.

That is possible. I have seen many byte loops like this. It's o.k. for tiny dynamic sized copies only (small static sized copies should be unrolled MOVE instructions). It's not much more costly for small dynamic copies to align the copy and use a longword loop as the vbcc memcpy() inline does (with a byte copy for remaining and unaligned bytes). This is much faster for larger copy sizes at the cost of a little larger code.

Thus, out of curiousity, which programs actually call CopyMem() then after all? It's really nothing that *should* be called if a call can be avoided.

I believe the biggest use of exec/CopyMem() is the ram disk but I recall the graphics or maybe layers library using it as well. I'm out of town at the moment or I would run the SnoopDOS script and tell you.

[matthey]

"ram-handler" may be among the most effective users of CopyMem(), maybe next to "scsi.device", but if you count the number of calls made to CopyMem() in the source code, "intuition.library" comes out on top. In ROM CopyMem() counts as a space saving measure, whereas on disk the operating system components happily use memcpy(), etc. instead.

Yes, I believe there were intutition.library CopyMem() calls also. Maybe even 2nd or 3rd most frequent or most bytes copied. I can't verify or do any statistics right now. Almost all of the AmigaOS CopyMem() calls are less than 1kB with the average size much less. There are calls even when the computer is mostly idle.