Hi Uz, > 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. From the Apple II user perspective I'd opt for that. > A disadvantage of options 2-4 is that it's probably me who is expected to > implement them:-) That in addition with the debugging issues (mostly again you expected to find / fix the problems) are enough to have me understand that you don't want to do it. > Anyway, are there more options? Opinions in favour of one of the options > listed above? In favour or against self modifying code? I'd be interested to understand how smc would look from the segments perspective. Would it go into the .code segement (which is then not r/o anymore) or would there be a new segment or would it go into the .data segment (like todays minimal amounts of smc) ? Regards, Oliver ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.Received on Fri, 4 Feb 2011 16:48:15 +0100
This archive was generated by hypermail 2.1.8 : 2011-02-04 16:48:28 CET