Irmen de Jong
Irmen de Jong
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.
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...
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 :(
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...
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
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...
release 11.3 contains a whole bunch of support for romable code now https://github.com/irmen/prog8/releases/tag/v11.3
Interesting, I'll have a look when time permits. ``__call__`` is discussed in #95
Not entirely sure. What happens if you try `proxy_object.__call__()` ?
An interfering problem is that the BatchProxy class relies on the `__call__` method to do the batch job