bslathi19/cc65
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity

Renamed INITBSS to INIT and INIT to ONCE.

Browse Source 
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.
This commit is contained in:
Oliver Schmidt
2016-03-06 21:26:22 +01:00
parent ab1600b346
commit 419eb700b5
132 changed files with 402 additions and 390 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
doc/atari.sgml
View File

@@ -743,7 +743,7 @@ segments should go above $7FFF.
<p>
The main problem is that the EXE header generated by the cc65 runtime
lib is wrong. It defines a single load chunk with the sizes/addresses
of the STARTUP, LOWCODE, INIT, CODE, RODATA, and DATA segments, in
of the STARTUP, LOWCODE, ONCE, CODE, RODATA, and DATA segments, in
fact, the whole user program (we're disregarding the "system check"
load chunk here).
<p>
@@ -796,7 +796,7 @@ SEGMENTS {
NEXEHDR: load = FSTHDR, type = ro; # first load chunk
STARTUP: load = RAMLO, type = ro, define = yes;
LOWCODE: load = RAMLO, type = ro, define = yes, optional = yes;
INIT: load = RAMLO, type = ro, optional = yes;
ONCE: load = RAMLO, type = ro, optional = yes;
CODE: load = RAMLO, type = ro, define = yes;
CHKHDR: load = SECHDR, type = ro; # second load chunk
@@ -808,7 +808,7 @@ SEGMENTS {
AUTOSTRT: load = RAM, type = ro; # defines program entry point
}
FEATURES {
CONDES: segment = RODATA,
CONDES: segment = ONCE,
type = constructor,
label = __CONSTRUCTOR_TABLE__,
count = __CONSTRUCTOR_COUNT__;
@@ -827,7 +827,7 @@ the MAINHDR segment get discarded.
<p>
The newly added NEXEHDR segment defines the correct chunk header for the
first intended load chunk. It
puts the STARTUP, LOWCODE, INIT, and CODE segments, which are the
puts the STARTUP, LOWCODE, ONCE, and CODE segments, which are the
segments containing only code, into load chunk #1 (RAMLO memory area).
<p>
The header for the second load chunk comes from the new CHKHDR
@@ -858,7 +858,7 @@ cl65 -t atari -C split.cfg -o prog.com prog.c split.s
<sect2>Low data and high code example<p>
Goal: Put RODATA and DATA into low memory and STARTUP, LOWCODE, INIT,
Goal: Put RODATA and DATA into low memory and STARTUP, LOWCODE, ONCE,
CODE, BSS, ZPSAVE into high memory (split2.cfg):
<tscreen><verb>
@@ -893,7 +893,7 @@ SEGMENTS {
CHKHDR: load = SECHDR, type = ro; # second load chunk
STARTUP: load = RAM, type = ro, define = yes;
INIT: load = RAM, type = ro, optional = yes;
ONCE: load = RAM, type = ro, optional = yes;
CODE: load = RAM, type = ro, define = yes;
BSS: load = RAM, type = bss, define = yes;
@@ -901,7 +901,7 @@ SEGMENTS {
AUTOSTRT: load = RAM, type = ro; # defines program entry point
}
FEATURES {
CONDES: segment = RODATA,
CONDES: segment = ONCE,
type = constructor,
label = __CONSTRUCTOR_TABLE__,
count = __CONSTRUCTOR_COUNT__;

20
doc/customizing.sgml
View File

@@ -78,15 +78,15 @@ vectors at the proper memory locations. The segment definition is:
<tscreen><code>
SEGMENTS {
ZEROPAGE: load = ZP, type = zp, define = yes;
DATA: load = ROM, type = rw, define = yes, run = RAM;
BSS: load = RAM, type = bss, define = yes;
HEAP: load = RAM, type = bss, optional = yes;
STARTUP: load = ROM, type = ro;
INIT: load = ROM, type = ro, optional = yes;
CODE: load = ROM, type = ro;
RODATA: load = ROM, type = ro;
VECTORS: load = ROM, type = ro, start = $FFFA;
ZEROPAGE: load = ZP, type = zp, define = yes;
DATA: load = ROM, type = rw, define = yes, run = RAM;
BSS: load = RAM, type = bss, define = yes;
HEAP: load = RAM, type = bss, optional = yes;
STARTUP: load = ROM, type = ro;
ONCE: load = ROM, type = ro, optional = yes;
CODE: load = ROM, type = ro;
RODATA: load = ROM, type = ro;
VECTORS: load = ROM, type = ro, start = $FFFA;
}
</code></tscreen>
@@ -97,7 +97,7 @@ The meaning of each of these segments is as follows.
<p><tt> BSS: </tt>Uninitialized data stored in RAM (used for variable storage)
<p><tt> HEAP: </tt>Uninitialized C-level heap storage in RAM, optional
<p><tt> STARTUP: </tt>The program initialization code, stored in ROM
<p><tt> INIT: </tt>The code needed to initialize the system, stored in ROM
<p><tt> ONCE: </tt>The code run once to initialize the system, stored in ROM
<p><tt> CODE: </tt>The program code, stored in ROM
<p><tt> RODATA: </tt>Initialized data that cannot be modified by the program, stored in ROM
<p><tt> VECTORS: </tt>The interrupt vector table, stored in ROM at location $FFFA

6
doc/ld65.sgml
View File

@@ -1032,11 +1032,11 @@ The builtin config files do contain segments that have a special meaning for
the compiler and the libraries that come with it. If you replace the builtin
config files, you will need the following information.
<sect1>INIT<p>
<sect1>ONCE<p>
The INIT segment is used for initialization code that may be reused once
The ONCE segment is used for initialization code run only once before
execution reaches main() - provided that the program runs in RAM. You
may for example add the INIT segment to the heap in really memory
may for example add the ONCE segment to the heap in really memory
constrained systems.
<sect1>LOWCODE<p>