This commit is contained in:
drmortalwombat 2025-02-28 16:20:10 +01:00
commit 0032d42b2c

View File

@ -15,7 +15,7 @@ When I started this project, I was under the assumption that the 6502 would make
The original plan was thus to compile to an intermediate language that would be interpreted, offering the 16bit support without the added code cost. This turned out to work great from a code size perspective, but the performance was poor. So I decided to give compiling to native code a shot. The original plan was thus to compile to an intermediate language that would be interpreted, offering the 16bit support without the added code cost. This turned out to work great from a code size perspective, but the performance was poor. So I decided to give compiling to native code a shot.
Most of the 6502 limitations can be overcome by carefull code analysis and optimizations. Most of the 6502 limitations can be overcome by careful code analysis and optimizations.
* A second data stack relieves the CPU stack. * A second data stack relieves the CPU stack.
* Static call graph analysis removes the need for a stack completely * Static call graph analysis removes the need for a stack completely
@ -744,7 +744,7 @@ Additional bss sections can be defined on request.
#pragma section( mybss, 0, , , bss ) #pragma section( mybss, 0, , , bss )
#pragma region( mybssregion, 0xc000, 0xd000, , , {mybss} ) #pragma region( mybssregion, 0xc000, 0xd000, , , {mybss} )
They will not be cleared on startup, so all variables placed in these segments will be unitialized. A common use for these sections is overlapping runtime variables with compressed load time assests that get expanded to their actual location during startup. They will not be cleared on startup, so all variables placed in these segments will be uninitialized. A common use for these sections is overlapping runtime variables with compressed load time assests that get expanded to their actual location during startup.
### Heap and Stack sections ### Heap and Stack sections