Nightly CI deprecated mingw64 packages in favour of ucrt64
package. Update the source build steps and documentation to
drop mingw support and only provide msys2/ucrt64 support.
fd2f5fa...
by
Kaito Sinclaire <email address hidden>
Be more neat & tidy with the .data section
f03250f...
by
Kaito Sinclaire <email address hidden>
Optimize C runtime initialization
Instead of clearing or overwriting memory one byte at a time, take
advantage of the fact that #__bss_start_in_ram and #__data_start_in_ram
are already guaranteed to be long-aligned, reserve d1-d7 and a0, and
movem from them directly into the correct locations.
This speeds up the initialization sequence for larger programs by
a couple orders of magnitude.
Because this code works in blocks of 32 bytes only, some chaff is left
over at the end of user memory (from 1 to 32 bytes worth). I don't
consider this an issue, because:
- That area is the heap, used for dynamic allocation, and using it
without clearing it out yourself is _already_ undefined behavior, and
- The previous code also left a byte of chaff in the same location
due to an off-by-one mistake.
The BSS segment is also initialized before the data segment, to avoid
a bug that the original code could occasionally encounter: Because it
was off by one in its calculations, clearing out the BSS segment could
result in clobbering the first byte of the data segment, if there was
no padding between the end of the BSS segment and the start of the data
segment (aka: if the length of the BSS segment was a multiple of 4).
In addition, the watchdog is only kicked once at the end of each loop,
because they now are fast enough that the watchdog resetting the system
is no longer a concern in even the worst cases, and it confers yet
another speedup.
Follow-up fix of linkscript after [1]. The linkscript
incorrectly relies on lazy evaluation to computes the
start of the .bss segment in RAM, leaving all linked
symbols incorrectly shifted in memory.
Re-work the backup RAM definition in the linkscript
with a proper MEMORY command, and expose macros in
the ngdevkit API to override the start and length of
the backup RAM at link-time.
After the linkscript update to support large P-ROMs [1,2],
the ordering of the bss and backup RAM segments has changed,
and this broke the logic used to compute the start of the .bss
segment in RAM. Fix accordingly.
After #78 and #81, the .bss segment is now linked prior to the
.data segment. The crt0 still assumes the opposite, so the
memory is incorrectly initialized.
Since the linker now exposes symbol __bss_start_in_ram, the crt0
no longer needs to assume any ordering. Fix it accordingly.
New API to map a specific chunk of the the second P-ROM into the
P-ROM2 memory address space at runtime (0x200000..0x2fffff).
To support bank-switching transparently, the order in which the
ELF sections are linked is modified: the devkit's code is always
linked in the first P-ROM, as well as all data. The user code
gets linked last, and all files whose path contain the substring
`__bank` get implicitly linked in the second P-ROM.
This changes the way the program ROM are linked. The
BRAM, BSS and RAM segments go first, the code itself being
linked at the very end of the P-ROM adress space.
The linker now allows the full 1MiB address space for
large P-ROM, as well as 2MiB non-contiguous P-ROM (2x1MiB).
This is a breaking change, the .text sections in the output
ELF file are no longer padded automatically. You now need to
add the proper padding when extracting code with objcopy.
dciabrin/ngdevkit-examples@03c250a0ee55bb05501a79ebb4c9401217d9959d
has been updated to implement padding appropriately.
