On Sun, Dec 12, 2010 at 2:58 PM, Ullrich von Bassewitz <uz@musoftware.de> wrote: > Your code is almost exactly identical to what I would have written, when > implementing it without changing the compiler structure. But it is just about > 10-15% of what has to be done, and the missing parts are the reason why I > didn't do it. Each and every optimizer routine that removes or rewrites code > has to check the new CodeEntry flag for every code line in question, otherwise > volatile processing might work in a few cases, but fail in many others. So > while it's a start, it is just that. Yeah. I pretty much just hacked in support for the one case I needed. ;) > So how to proceed? I'm willing to apply the patch in this or a similar form, > but everybody has to realize that this will change the current situation only > a bit. Instead of "volatile is parsed but ignored", which is a clear and > unambiguous statement, it would then be "volatile is parsed and might > sometimes work". If this is considered an improvement, I will apply the patch. This is a good question.... I'm not quite I can provide any valuable input. Is 10% of volatile better than 0%? It is if you're the one who wants to use that 10%. ;) Also, does this help a common case for using volatile? Given the PEEK/POKE macros, accessing specific address is pretty common, and often those addresses are hardware registers. Some questions... is volatile something you'd like to eventually fully support? Does this patch help get you there? If so, perhaps full volatile support could be added piecemeal, over time, rather than waiting for some grand redesign, in which case this patch is the first step towards that. -Dave ---------------------------------------------------------------------- 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 Dec 18 05:44:07 2010
This archive was generated by hypermail 2.1.8 : 2010-12-18 05:44:11 CET