Decide how to treat rom addresses, segmented addresses, physical addresses, etc

[AngheloAlf]

There has been the never ending discussion of how we should treat the various type of addresses that do not point to vram (ie, can't be derefernced directly).

Currently we use the void* type for holding vram pointers in struct members, temps, function parameters, etc. And cast them to uintptr_t when we need to do arithmetic on them.

We may want to have a distinction for the other numerical addresses.

• Rom address. Personally I would like to propose a RomOffset type, which would be the uintptr_t equivalent for rom addresses, allowing to represent this type, differentiate it from virtual addresses and allow arithmetic on them.
• Segmented address. @EllipticEllipsis brought up this possibility.
• Physical address. Isn't this the same as a rom address? 🤔

[mzxrules]

I don't think it's a good idea to make distinct types for virtual addresses (80xx xxxx), physical addresses (00xx xxxx; this is not a rom address), and segment addresses (x0xx xxxx to xFxx xxxx) because you are allowed to freely transmute between the three types of addresses.

For example, bgcheck style collision references various structures by segment address at compile time, but when the data is loaded into ram, the addresses are converted in place into virtual addresses.

Furthermore, if you assume virtual and physical addresses are limited to a 16 MB address space (a fairly reasonable assumption given the N64 only had a maximum expansion of 8 MB of ram), physical and virtual addresses will map to segment 0 and can be passed in anywhere a segment address is expected. This is an intentional design of the segment address system.