On 2011-02-04, at 15:22, Ullrich von Bassewitz wrote: > Christian Krüger, who has already contributed optimized memxxx functions has > sent me a memset replacement that uses self modifying code. It performs > significantly better than the existing one, especially for larger memory > blocks and is based on two independent include files that contain macros and > contants for developing modules containing self modifying code. /me was never a big fan of smc, and very rarely used it even back in the days. But I guess we all know what are the potential advantages. Like a step between "proper" code and programatically generated code (LDA STA LDA STA LDA ...), which can bring even more substantial performance improvements when dealing with large (from 6502 POV) memory blocks. memxxx seem almost like natural candidates for consideration here. > > Now the question is what to do with it. > [...] > As I see it, my options are: > If my two pennies are of any value then I find > 2. Accept replacement functions using smc, but let them have different > names, so a programmer must explicitly call the smc version. most appealing. Reasons for that: 1) Smc's disadvantages, which you accurately named make it something one (IMHO) should not expect being there as default. Especially in an overall very "clean" and "properly" behaving environment as cc65 so far seem to be. We probably don't have to hold our breaths waiting for next generations of 65xx processors with caches and pipelines but still - to me "unclean" is "unclean" and prefer it to be included at explicit wish of an educated (the one who reads docs :) user. 2) As I mentioned earlier - use cases for those extra performing functions are not always obvious. Yes, ultra-fast I/O, some soft-blitter gfx routines (I recall I used smc e. g. for gfx cleans and fills) but in general there would be no strikingly obvious need for common use, I believe. 3) With this option #2, like with the just discussed __fastcall__ - the extra performance comes at explicit wish. Understanding and having in mind what it does and what the potential pitfalls might be seems to me like the right approach. -- SD!---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.Received on Sat Feb 5 01:09:53 2011
This archive was generated by hypermail 2.1.8 : 2011-02-05 01:09:58 CET