Improve romability of low-level libs

[adiee5]

This PR adjusts the low-level libraries, so that they can work in ROMed environments. In most cases, the problem was that these functions had helper variables defined inline. since none of them actually have any init value, we move the variables to BBS section (like prog8 codegen does) where we can ensure, that variables land safely in RAM.

When it comes to more controversial changes, conv.string_out is changed to ubyte[16] type. I don't think this change is going to break anything, since most of the time, those 2 types work identically and the variable is usually delegated to just internal stuff anyways.

There are 3 functions that are not fixed by this PR – math.randword, prog8_lib.arraycopy_split_to_normal_words and arraycopy_normal_to_split_words. All of them currently rely on self modifying code.

The first one requires the 4 variables to be initialized to specific values. We could try to allocate them to the uninitialized slabs_BSS sections and yield results based on the uninitialized values, but this might be risky (some emulators may initialize all the memory to 0, or in general the existing values may yield results, that aren't too good).

The other two use self-modifying code for pointer access. The way prog8 creates .asm files doesn't allow low-level assembly code to allocate variables in zero-page, so it's not an easy fix like others. Changing them to pointer access may also decrease the execution speed of the function. The solution here might be to just create an alternative variants of the subroutines for ROMed targets and just use the new functions instead of the regular ones. still, ZP allocation might be a problem.

[irmen]

There are a few more spots that have inlined variables.
For example syslib.p8/save_prog8_internals() (for multiple compilation targets!)
and syslib.p8/save_virtual_registers() (for multiple targets)
and syslib.p8/save_vera_context() only for x16 ofcourse
and syslib.p8/restore_irq() only for cx16 somehow

and floats.asm (floats_temp_var) <- However I think we can argue that you lose floating point support if you choose to make romable code (because the floating point rom routines won't be available if your code is the one that is running in the rom bank)

I've put some comments in in those places "TODO: Romable"

[adiee5]

right, I only really targeted multi-platform code (things present in root directory of prog8lib). but yeah, i guess making the targeted code more romable at the same time may be a good idea too

[adiee5]

For example syslib.p8/save_prog8_internals() (for multiple compilation targets!)
and syslib.p8/save_virtual_registers() (for multiple targets)

as a side-note, I've already made these 2 romable in the nes target

[irmen]

Not requiring you to do everything here in this PR. Just mentioning some observations for now.

[adiee5]

fair enough

[adiee5]

and floats.asm (floats_temp_var)

what's this one?

[irmen]

and floats.asm (floats_temp_var)
what's this one?

Used in floating point expressions to store intermediate values. But I think it's best to just disable floating point support if you do %option romable

[adiee5]

ahh, it's located in c64 libraries, ok, I see now.

But I think it's best to just disable floating point support if you do %option romable

yeah, it's probably not that useful (though still, probably possible thanks to JSRFAR)

[adiee5]

Anyway, I handled the syslibs now