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. (update: Fixed all know occurrences)

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

• add a compiler flag to report self-modifying code issues (%option romable)
• 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 (I hope I got them all, but maybe I missed a few cases)
• fix all non-ROMable code in the libraries (or document the routine explicitly as not ROM-compatible)
• handle readonly str and initialized arrays better maybe with @mutable (see discussion below)
• add switch to set an explicit memory address for the BSS variables section?
• documentation

[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.

[irmen]

I've added a %option romable that may be a start for the compiler to create romable code.

For now, it starts by printing warnings for the places in the code generator where I am certain it is creating self-modifying code which is not romable.

There is a LOT more work to do. (see top message)

[adiee5]

Remember to look at the pull request: #160

[irmen]

Sure. Combing through the standard library asm code is needed too and I think there will be a lot more places than what you already found in the PR :(

[irmen]

some work has been done to get rid of many inline variables. Some still remain for less common scenarios, and the BSS area still ends up in ROM address space I think.

[adiee5]

and the BSS area still ends up in ROM address space I think.

Command line arguments allow us to relocate the BSS (which at least helps us in the NES target). When it comes to BSS location on targets such as C64 and CX16, it's probably pretty dependent on the specific use case of the program, so the only option is to have the people make custom configs for their programs (or give more control over BSS location in command args)

[adiee5]

Of course, the default option of simply using default spaces (golden and high) is always here and may be enough for some projects

[irmen]

Had to make a fix to the memtop assembler check, but using -varsgolden or -varshigh now both work and will indeed put the variables in the corresponding RAM memory area

[irmen]

if the compiler can detect assignment to elements of a string or array (that will be stored in ROM) it will flag that as an error now. Assigning through a pointer or other means cannot be caught and are just... POOF

[irmen]

release 11.3 contains a whole bunch of support for romable code now
https://github.com/irmen/prog8/releases/tag/v11.3