ideas to improve compiler support for romable code

[irmen]

To be able to build programs that can be put into ROM (for rom programs or stuff like a NES cartridge game, for instance), a couple of things are required.
Most notably:

• no "inline" variables (only zeropage and bss)
• no self-modifying code

Currently both are not achieved by the compiler.

An idea around better situation concerning self-modifying code is:

• add a compiler flag to report self-modifying code issues
• make sure that the compiler doesn't generate any self-modifying code in the codegen
• or, alternatively, print a warning/error when it (still) does
• introduce a tag for asmsub's that marks them as using self-modifying code. This requires a review of ALL of the library asmsub routines and mark them correctly.
• this does leave all other included or inlined asm to do whatever it likes undetected.....

[tallLeRoy]

the tag should make it out the the listing file, so after compile the coder can search for the tag in the listing to find the areas not ready for ROM

[irmen]

Probably should ignore the issues with the library code at first and concentrate on looking what needs to be done to get the code-generator in shape for this.

[adiee5]

• no "inline" variables (only zeropage and bss)

not achieved by the compiler.

While compiler doesn't necessarily take care of that, there are still ways to get around that in prog8 – programmer does have a control over whenever a variable ends up in a inline (by using str and array[] = [contents] types) or bbs (by using array[len] types).

I guess for now we could just flag those inline types as immutable in ROMed environments (NES target and romable flag) and make compiler try to throw errors when trying to modify stuff in those immutable variables and expect developers to use mutable equivalents if they want their code to work in romable environments. Obviously such checks won't work if you pass the variable as a pointer, unless we do a rust thing and we add ability to add some kind of @mutable flag to function parameters in function signatures in order to inform programmers and the compiler, that the function expects the data behind the pointer to be modifiable and so compiler could throw warnings/errors when user explicitly passes a immutable variable into such function.

The more proper way (and really the only way) of handling those inline variable stuff that doesn't require a programmer to use separate programming tactics when programming for a ROMed environment is to allocate those variables in RAM and load the initialization values from rom while starting a program, which would significantly increase the bootup time. ca65 makes that easier by making sections have "LOAD" and "RUN" addresses. Sadly, I'm not sure if similarly convenient thing can be done in 64tass. Since we copy stuff from rom to ram, I guess it could be possible from that point to apply the same memory optimization for string variables in romable environments as with string literals currently.