Wonderful Toolchain Wiki

User Tools

Site Tools

Trace:
wswan:guide:memory_management

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
wswan:guide:memory_management [2025/04/03 18:03] – [Placing in specific memory locations] asiewswan:guide:memory_management [2025/04/03 18:24] (current) – [Addressing RAM and ROM] asie
Line 6: Line 6:
   * The combined segmentation and banking benefits from a ROM layouting scheme which takes it into account.   * The combined segmentation and banking benefits from a ROM layouting scheme which takes it into account.
  
-===== Addressing RAM and ROM =====+===== Addressing RAM and ROM in C =====
  
 In a C environment, by default, //near// pointers are utilized - they're smaller and faster to use, but they can only point to the program's default //data segment// - for all ''wswan'' targets, this is the console's internal RAM (IRAM). In a C environment, by default, //near// pointers are utilized - they're smaller and faster to use, but they can only point to the program's default //data segment// - for all ''wswan'' targets, this is the console's internal RAM (IRAM).
Line 13: Line 13:
  
 <code C> <code C>
-// The variable below will be stored in IRAM, even if it's declared const.+// The variable below will be stored in IRAM, even if it's declared as read-only (const).
 static const uint16_t table_iram[] = {0, 1, 2, 3}; static const uint16_t table_iram[] = {0, 1, 2, 3};
  
-// The variable below will now be stored in ROM instead of IRAM.+// The variable below will now be stored in ROM instead of IRAM, as it is read-only and far.
 static const uint16_t __far table[] = {0, 1, 2, 3}; static const uint16_t __far table[] = {0, 1, 2, 3};
 +
 +// As will this one, except it's not static, so you can reference it in a .h file...
 +const uint16_t __far global_table[] = {0, 1, 2, 3};
 +
 +// ... like so.
 +extern const uint16_t __far global_table[];
  
 void process_table_iram(uint16_t *tbl); // This function can accept pointers to IRAM only. void process_table_iram(uint16_t *tbl); // This function can accept pointers to IRAM only.
Line 33: Line 39:
   * ''%%__wf_iram%%'' - points to IRAM on every subtarget.   * ''%%__wf_iram%%'' - points to IRAM on every subtarget.
  
-===== Placing in specific memory locations =====+===== Addressing RAM and ROM in assembly =====
  
-By default, as discussed above, the following sections are placed in the ROM as follows:+The linker places code and data in RAM and ROM using sections. These sections are used by default by the C compiler:
  
-  * ''.fartext'' - code, last 768 KiB of ROM +  * ''.fartext'' - far code, last 768 KiB of ROM 
-  * ''.farrodata'' - data, last 768 KiB of ROM+  * ''.farrodata'' - far read-only data, last 768 KiB of ROM
   * ''.text'' - code, RAM   * ''.text'' - code, RAM
   * ''.rodata'', ''.data'' - data, RAM   * ''.rodata'', ''.data'' - data, RAM
   * ''.bss'' - zero-filled data, RAM   * ''.bss'' - zero-filled data, RAM
  
-These sections are automatically used in C code. However, what if you want to place your section in a specific area of RAM? On the WonderSwan, especially the Color model, there are [[https://ws.nesdev.org/wiki/Memory_map#Internal|many restrictions]] as to where or with what alignment certain types of data (screen tables, tiles, audio wavetables) may be placed. Alternatively, what if you want to place your code/data in a manually bankable area of ROM?+Note that these act as prefixes - ''.text.a'' and ''.text.b'' will both be placed in RAM. This matters in particular for far code/data - ''.fartext.a'' and ''.fartext.b'' will both be placed in the last 768 KIB of ROM, but are allowed to use different 64 KiB segments to do so. 
 + 
 +To address RAM and ROM in assembly, one can use these very same sections manually. 
 + 
 +<code> 
 +.section .fartext.my_rom_code_segment, "ax" 
 +.section .farrodata.my_rom_data_segment, "a" 
 +.section .text.my_ram_code, "ax" 
 +.section .data.my_ram_data, "aw" 
 +</code> 
 + 
 +The quoted component refers to section flags. The most useful ones are: 
 + 
 +  * ''a'' - section is allocated in RAM/ROM 
 +  * ''w'' - section is writable 
 +  * ''x'' - section is executable 
 +  * ''R'' - section is retained even if not used by any code 
 + 
 +All section flags are listed in [[https://wonderful.asie.pl/doc/binutils-ia16/as.html#Section-Name-Substitutions|the assembler manual]]. 
 + 
 +===== Advanced section names ===== 
 + 
 +What if you want to place your code or data in a specific area of RAM? On the WonderSwan, especially the Color model, there are [[https://ws.nesdev.org/wiki/Memory_map#Internal|many restrictions]] as to where or with what alignment certain types of data (screen tables, tiles, audio wavetables) may be placed. Alternatively, what if you want to place your code/data in a manually bankable area of ROM?
  
 To make this possible, Wonderful's linking approach has been extended to allow special section name patterns to be used. For example: To make this possible, Wonderful's linking approach has been extended to allow special section name patterns to be used. For example:
wswan/guide/memory_management.1743703416.txt.gz · Last modified: 2025/04/03 18:03 by asie