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