On 2013-01-25, at 10:31, Ullrich von Bassewitz wrote: > One or more memory areas go into one file. This is how it has been designed. > >> But I am wondering whether there is something that I could call a "more >> elegant" solution. Or just want to be sure that there isn't, before expanding >> my config like above :-) > > Actually I do consider this as elegant. I don't find it ugly either. That's why I used quotes. But still somewhat unintuitive and requiring lots of config lines to get the result. > Configuring multiple files for a > memory area would be highly complex and probably not easy to understand I was thinking about something like (optional of course) "file" attribute to SEGMENT entry, prioritised below that of MEMORY entries. I tend to believe that this would actually be somewhat easier to understand than the current setup. I mean, I probably would find it more intuitive, at least in the given case, to define one (1) memory area (because in reality it would fully map 1:1 between the entry and the physical MEM then) and have several (content) segments that could go into this very same MEM. This way memory could be modelled more intuitively due to being direct representation of the physical mem. And the number of config lines needed to achieve the result would be cut almost by half. Having priorities on the "file" attribute would allow all existing configs to continue to work, possibly with warning if competing entries got detected. > (many people have problems grasping linker config files at all). I know :-) And I wouldn't try to make things even more difficult to grasp :-) -- 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 Fri Jan 25 13:15:37 2013
This archive was generated by hypermail 2.1.8 : 2013-01-25 13:15:41 CET