From: Greg King (gngking_at_erols.com)
Date: 2003-08-16 06:40:14
From: Ullrich von Bassewitz; On Date: Monday, August 11, 2003, 04:03 PM > > I've started to change the heap using your idea with small modifications; > but when doing so, I found a few problems. Maybe you (or someone else) > can help me solve them. > > 1. The suggested solution does not work for configurations where the > start-address is passed via the command-line, using %S in the linker > config. Configurations that have this problem are: > lunix/osa65 and none. 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. I do not think that none.cfg's problem is "start=%S" -- at least, not exactly that. I think a better description is that the "none" target must have an open-ended (very loose) nature. Its purpose is to avoid, as much as possible, putting built-in restrictions on what we can do with a program. But currently, STK's address cannot be set by ld65's command-line. 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;" ]). > > 2. There are some configurations that do actually cover systems with > different amounts of memory available. One system is the C16 (which > supports 16 and 32KB of memory) and the PET, which comes with 4, 8, > 16 and 32K of memory. Currently, the startup code determines how > much memory is available and adjusts the stack-pointer accordingly. > With the old heap routines this worked, since they calculated > the heap-end from the stack-pointer. Using your idea, this does no > longer work. While the old code was not perfect (the linker would > not detect a program too large to fit into memory), > having 4 different memory configurations just for the PET machines > sounds even worse. After I sent my EMail [naturally, it's always "after" :-( ], I noticed it in the Apple and Atari start-up files. I didn't notice those others. [I really must study all of the start-up files much more! :-) ] Darn! I had been _very_ proud of my "invention." (I guess that I should have known -- nothing in life ever truly is perfect.) :-/ I will study the problem. (I'm thinking out loud, now) ... We will need to back away from my idea, a little bit -- to gain a compromise. (I already did it once, in the stack-checker. Originally, I made the stack be an actual, named segment. And, the low-water mark was built into that segment's structure. The checker did not need a constructor. But, the LUnix library could not use it. I remembered that you do not like to see targets replace common files if they really do not need to do it. So, I returned to a design that constructs the mark. [I now have learned that I must have been psychic. ;-) Those other targets need that constructor, too.]) We probably will change __heapend back into a pointer-variable (while keeping __heaporg as an immediate address). Then, the problem becomes: Can we write a constructor (or, constructors) that sets heapend's value from different sources -- depending on the configuration? There are two environments: pre-set stack and "run-set" stack. 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. That plan would be compatible; but, the "run-set" configurations would not be flexible. (The person who started this discussion wanted to move the Atari's heap to different places.) So, we would need to find a way to let the scripts choose between the stack and the linker-symbol. [Of course, those musings come from a person who does not know how you have changed my original proposal. :-) ] ---------------------------------------------------------------------- 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 07:04:47 CEST