Compact/large memory models

[asiekierka]

Opening an issue so it's not forgotten, as one doesn't seem to be already open. The main issue seems to be dynamically switching address space emitting so that "far" pointers are GENERIC, while "near" pointers are not.

I've been thinking about your remark wrt performance - however, there's an usability issue worth discussing in the context of my WonderSwan toolchain: it would be good from an user experience perspective to have memcpy() operate on far pointers by default (as ROM->RAM and RAM->save RAM copies are likely to be fairly common operations), but GCC assumes the presence of a memcpy() and memset() which follow the C standard and accept non-address-spaced pointers in init_block_move_fn and init_block_clear_fn.

Other advantages would include broadening the amount of DOS C software that can be compiled with gcc-ia16 - one found in the wild which would be interesting to support is that rendering benchmark I brought up earlier.

[asiekierka]

I've started tinkering with an implementation locally, which made me wonder an interesting question. Currently, near addresses are generic space and far addresses are a named address space. How would this be handled in compact/large models?:

• variables and data would automatically be assigned to the far address space, like with far text modes (medium) now,
• the role of the generic space could also change depending on compiler configuration; three address spaces: generic (near or far depending on data configuration), near (near), far (far).

[FrenkelS]

Other advantages would include broadening the amount of DOS C software that can be compiled with gcc-ia16 - one found in the wild which would be interesting to support is that rendering benchmark I brought up earlier.

I've changed the code of that benchmark a bit so it can use the small memory model, but somehow gcc-ia16 performs very poorly in that benchmark.