From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2003-08-16 11:09:28
Hi! On Sat, Aug 16, 2003 at 12:40:14AM -0400, Greg King wrote: > The LUnix library does not use my idea, anyway. It is like the GEOS > library: it does some things differently, so that it can take advantage > of OS features. It gets its stack and heap from LUnix's dynamic memory. While it's ok to have machine specific stuff, and I've tried to make it possible to replace standard files from the cc65 library easily, there is one really, really big problem with it: More platform specific stuff means that the sources become much harder to maintain. This is the reason why I'm trying hard to put as much code as possible into the common libraries. If I have it there, it is used by all platforms, and changes can be tested by using testcode on one, arbitrary choosen platform. Having 10 different implementations for 10 different platforms is a maintenance nightmare, and each platform specific file increases the chance that there will be undetected bugs, and that one platform starts to lag behind others. > I think that it would be useful to many of the targets if you added > another address option: %S, %E (or maybe, more than two). They could > be used to change the lower- and upper-bounds of the memory that a program > normally would use (STARTADDRESS would set the standard locations > [maybe it should be "ADDRESS: start=$xxxx, end=$xxxx;" ]). I have to admit that I don't like that idea. It adds a special solution for a special problem. It is my experience that once you start with special solutions like that, you end piling up more and more features each solving just one very special problem. Having a more general solution is what I would prefer. This could be adding expressions to the linker configs as I had already mentioned when the discussion started. Being able to calculate things within a linker script would solve a lot of problems including the one we have now: One can easily calculate the size of the RAM memory area if the start address is given, so there's no need for %E. The location of the heap and stack could be based on the location of any of the segments, so it would also solve the problem we have on systems with non contignous memory (like the NES). And so on... The reason why I wanted to avoid adding expressions is that it is work for me, and I do really have enough unfinished things within this project. > Darn! I had been _very_ proud of my "invention." (I guess that I should > have known -- nothing in life ever truly is perfect.) :-/ Your idea was definitely a good one! I liked it and wanted to use it (in fact, I have new versions of almost all linker configs lying around). The big advantage of your idea is that it saves me a lot of work, because I don't need to add expressions to the linker:-) > A first -- very crude -- attempt: move the original constructor out of the > common file, and into files in each target directory. It would compute > from the stack-pointer, on "run-set" targets. It would use > __HEAPEND_RUN__, on pre-set targets. Yes, I also had this idea when thinking about the problem. But for now, my suggestion would be to leave it as it is, until things have settled. I have a list of "to do" things for the current development branch, and I would really like to get them done before adding new "big" things. > [Of course, those musings come from a person who does not know how you > have changed my original proposal. :-) ] I didn't change much of it. For one I've renamed STK to STACK:-) The other thing was that I didn't like to use labels as immediate values, so I would have left the __heapend and other variables in place. This did in fact remove the need for the constructor alltogether, since these variables could be initialized by linker calculated expressions. Regards Uz -- Ullrich von Bassewitz uz_at_musoftware.de ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo_at_musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2003-08-16 11:09:53 CEST