You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This came up in #315, and it's discussed more thoroughly in the tail end of that discussion.
Summary:
I think there's three aspects of the commodore family targets that come into conflict:
That the only real execution environment that loads programs is BASIC
That they exit by returning (from the above, always to BASIC)
That they clobber BASIC ZP.
If any of the above weren't true, there'd be a way to use the resulting PRG files such that they cleanly returned, but as is it feels like one of the second two points should change. We may want to either split the commodore targets into BASIC and no-BASIC variants, or if it's possible, provide a link-time configuration symbol for this. Whatever the default ends up being, it should infinite loop if it isn't safe to return to BASIC; that at least may let one inspect the output.
The easiest change we could make to make this consistent would be to change the commodore targets to exit-loop instead of exit-return; that's one line of CMake. It looks like cc65 doesn't use the BASIC ZP at all and returns. That's one possible configuration. Another is to save and restore BASIC ZP on entry/exit and use it, and another is to clobber it and never return. Ideally there would be a simple way to spell each of these for each commodore target in the SDK, and hopefully, without too much monkeying around in linker scripts. That's the part that needs designing; we've built out a huge degree of this kind of configuration in the NES targets, so it may be possible, but it can be tricky.
The text was updated successfully, but these errors were encountered:
I think saving and restoring BASIC ZP makes sense as a library actually. We already have symbolic names for the BASIC ZP area, so we could register actions in early init/late fini to save and restore to a buffer. The buffer would need to be defined in a .s file per target (different sizes), but that's no major issue either.
So, for now I'm going to do the exit-loop change; it's easy, and it provides a safer version of what the SDK does already. I do think it's a good default; BASIC uses a ton of ZP, and doing something extra to save/restore seems largely better than disallowing use. I think some symbol work could make the ZP range used configurable, so we may need to just make sure that it's possible to link against -lexit-return directly (I think it should be?)
This came up in #315, and it's discussed more thoroughly in the tail end of that discussion.
Summary:
I think there's three aspects of the commodore family targets that come into conflict:
If any of the above weren't true, there'd be a way to use the resulting PRG files such that they cleanly returned, but as is it feels like one of the second two points should change. We may want to either split the commodore targets into BASIC and no-BASIC variants, or if it's possible, provide a link-time configuration symbol for this. Whatever the default ends up being, it should infinite loop if it isn't safe to return to BASIC; that at least may let one inspect the output.
The easiest change we could make to make this consistent would be to change the commodore targets to exit-loop instead of exit-return; that's one line of CMake. It looks like cc65 doesn't use the BASIC ZP at all and returns. That's one possible configuration. Another is to save and restore BASIC ZP on entry/exit and use it, and another is to clobber it and never return. Ideally there would be a simple way to spell each of these for each commodore target in the SDK, and hopefully, without too much monkeying around in linker scripts. That's the part that needs designing; we've built out a huge degree of this kind of configuration in the NES targets, so it may be possible, but it can be tricky.
The text was updated successfully, but these errors were encountered: