Re: [cc65] Modules with self modifying code

From: <silverdr1wfmh.org.pl>
Date: 2011-02-05 13:13:21
On 2011-02-05, at 12:18, Ullrich von Bassewitz wrote:

>>> 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:
> 
> In the current situation, I do also see this as the most appealing approach:
> 
> [...]
> 
>  - Programmers must explicitly choose to use self modifying code, which is
>    hopefully like signing "I know what I do and I promise to be careful".
> [...]
> 
> So how about an include file smc.h and a function prefix of smc_, which would
> mean functions are named smc_memset() and similar?
> 

For a second I was thinking of fast_memset() as it would underline the actual advantage, but after that second I dropped it and believe that smc_ is better as it should force some curiosity to read the docs before usage, rather then encouraging reflexive use ;-)

> Platform specific functions should still go into the platform header files,
> even if they use self modifying code. Usage of smc in platform specific
> functions should be documented in the function reference.
> 
> Does that sound ok?

Yes.

> I'm not sure about the segment question, Oliver brought up. When choosing
> option 2, where a programmer must explitly include and call smc functions, I
> would even find it acceptable to place these functions in the CODE segment.
> But that doesn't cover target specific functions with smc. We can also use
> another segment like SMCCODE, but the segment list in the config files is
> already quite large and it's difficult for a newcomer to understand the
> purpose of all the segments.

It is a valid question, especially in terms of "clean" approach. I think I'd vote (even if not vehemently :) against new segment. Current set can already be somewhat confusing (as you also noted), while "tainting" ro with writes doesn't seem to be right either.

I tend to believe that the less evil (even if painful for a perfectionist mind) approach is to put it into .data, which is where "target specific functions with smc" reside, right?

-- 
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 13:13:30 2011

This archive was generated by hypermail 2.1.8 : 2011-02-05 13:13:33 CET