Re: [cc65] Modules with self modifying code

Hi,

On Fri, Feb 04, 2011 at 03:22:44PM +0100, Ullrich von Bassewitz wrote:
> In the past, I've refrained from using self modifying code, because it is not
> romable, quite difficult to debug, and has more potential for errors in my
> experience. In addition, some of the functions that would benefit most from
> smc are inlined by the compiler, so the library function is never called. And,
> there are platforms that have programs in ROM, so they can use these modules
> only with tricks.
> 
> On the other side, there are definitely cases, where problems are almost
> impossible to solve without self modifying code, and there are other cases,
> where smc gives a huge performance increase.

Yeah. With a CPU like 6502, every possibilities must be used to gain some
speed, not a much big deal on a modern CPU with clock rate in the GHz scale
... Even if self modifying is "ugly" sometimes ...

However there are disadvantages too, for sure. I think it's nice to have
those _IF_ there are alternatives too (not self modifying code), then user
can choose (also because of ROMable/RAM code, etc etc). I would say, it's a
bit risky to accept self modifying code if there is no alternative or making
self modifying code by default, also because it was not the default before.

So I would vote for point 2 or 3 ... Point 4 is still risky, because of the
word "usually" :) Also with points 2/3, user is much more capable of knowing
what he/she really does.

>   1. Don't accept modules/changes containing smc. There's nothing that
>      prevents programmers to use smc on their own as it was before. To support
>      people writing their own modules, Christians include files could be
>      incorporated into the library, so there's a base to build on.
> 
>   2. Accept replacement functions using smc, but let them have different
>      names, so a programmer must explicitly call the smc version.
> 
>   3. Accept replacement functions and create a separate library together with
>      a small script that allows an end user to replace the modules in a target
>      library with smc versions.
> 
>   4. Accept replacement functions and add them by default to the target
>      libraries of the platforms where programs are usually run in RAM. Since a
>      programmer must still be able to write romable code, there must be some
>      measure to create a library without smc code.
> 
> A disadvantage of options 2-4 is that it's probably me who is expected to
> implement them:-)

:)

> Anyway, are there more options? Opinions in favour of one of the options
> listed above? In favour or against self modifying code?
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.