1
0
mirror of https://github.com/cc65/cc65.git synced 2024-12-27 15:29:46 +00:00
Commit Graph

11 Commits

Author SHA1 Message Date
bbbradsmith
d4c4786ff0 undo change of INIT to bss for configurations that were also using rw to reserve space, add a comment documenting the reason 2023-09-05 00:24:18 -04:00
bbbradsmith
2431fb7d85 correct INIT segment semantic is bss, make this consistent across all default cfg 2023-08-19 13:08:46 -04:00
Oliver Schmidt
d5092d2d3f Consider the segment attributes 'define' and 'optional' mutually exclusive.
In normal situations it isn't too useful to define symbols for optional segments as those symbols can't be presumed to be always present.

I in fact suspect that most currently present combinations of 'define' and 'optional' aren't useful - apart form the overlay configurations of course.
2016-03-17 21:31:43 +01:00
Oliver Schmidt
a3a22733f8 Cleaned up C64 linker configs.
The BSS segment and the ONCE segment share the same start address. So they need to be placed in two different memory areas.

So far BSS was placed in the MAIN memory area and ONCE was placed in an additional memory area. Both memory areas were written to the output file. They just "happened" to be loadable and runnable at a stretch.

Now ONCE is placed in the MAIN memory area and BSS is placed in an additional memory area. Only MAIN is written to the output file. It becomes more obvious that BSS is "just" defined to share memory with ONCE.
2016-03-13 14:32:07 +01:00
Oliver Schmidt
419eb700b5 Renamed INITBSS to INIT and INIT to ONCE.
The way we want to use the INITBSS segment - and especially the fact that it won't have the type bss on all ROM based targets - means that the name INITBSS is misleading. After all INIT is the best name from my perspective as it serves several purposes and therefore needs a rather generic name.

Unfortunately this means that the current INIT segment needs to be renamed too. Looking for a short (ideally 4 letter) name I came up with ONCE as it contains all code (and data) accessed only once during initialization.
2016-03-06 21:27:19 +01:00
Oliver Schmidt
3d08abcfa8 Load INITBSS segment from disk.
Conceptually the INITBSS segment is not initialized in any way. Therefore it makes sense to not load it from disk. However the INIT segment has to be loaded from disk and therefore moved to its run location above the INITBSS segment. The necessary move routine increases runtime RAM usage :-(

Therefore we now "unnecessarily" load the INITBSS segment from disk too meaning that the INIT segment is loaded at its run location. Therefore there's no need for the move routine anymore.

After all we trade disk space for (runtime) RAM space - an easy decision ;-)

Notes:

- The code allowing to re-run a program without re-load present so far could not have worked as far as I can see as it only avoided to re-run the move routine but still tried to re-run the code in the INIT segment that was clobbered by zeroing the BSS. Therefore I removed the code in question altogether. I'm personally not into this "dirty re-run" but if someone wants to add an actually working solution I won't block that.

- INITBSS is intentionally not just merged with the DATA segment as ROM-based targets can't reuse the INIT segment for the BSS and therefore have no reason to place the INIT segment above INITBSS.

- Because ROM-based targets don't copy INITBSS from the ROM (like it is done with the DATA segment) all users of INITBSS _MUST_NOT_ presume INITBSS to be initialized with zeros!
2016-02-28 19:45:36 +01:00
Oliver Schmidt
0ee9b2e446 Changed run location of INIT segment.
So far the INIT segment was run from the later heap+stack. Now the INIT segment is run from the later BSS. The background is that so far the INIT segment was pretty small (from $80 to $180 bytes). But upcoming changes will increase the INIT segment in certain scenarios up to ~ $1000 bytes. So programs with very limited heap+stack might just not been able to move the INIT segment to its run location. But moving the INIT segment to the later BSS allows it to occupy the later BSS+heap+stack.

In order to allow that the constructors are _NOT_ allowed anymore to access the BSS. Rather they must use the DATA segment or the new INITBSS segment. The latter isn't cleared at any point so the constructors may use it to expose values to the main program. However they must make sure to always write the values as they are not pre-initialized.
2015-10-14 22:52:09 +02:00
Greg King
ca70700a0b Restored the old C-stack initiation code.
I had forgotten that the stack must be put below the CBM overlays.
2015-10-08 06:04:49 -04:00
Greg King
8a880580dc Reduced the size of the moveinit subroutine.
Made other changes that were recommended by Oliver.
* Changed its name from move_init to moveinit.
* Used self-modifying code in the subroutine.
* The INIT segment doesn't need to be optional (it's used by the start-up file).
2015-10-07 14:56:14 -04:00
Greg King
074e10d288 Adapted, to the c64 target, the INIT-segment overlay scheme from the apple2 targets.
When a program starts running, INIT is moved from one place to another place.  Then, INIT's code is executed; and, the first place is re-used for variables.  After the INIT code has finished, the second place can be re-used by the heap and the C stack.  That means that initiation code and data won't waste any RAM space after they stop being needed.
2015-10-05 05:47:43 -04:00
Oliver Schmidt
37c492b544 Replaced builtin linker configs with ordinary .cfg files.
The benefits are:
- Independency of ld65 build from perl
- More transparent behaviour
2013-04-09 23:09:46 +02:00