Shiftability

[bates64]

From @ethteck on Discord:

Disassemble all data

basically anything in the splat.yaml that's "data" (no dot before it) or "bin" is asm data or just binary data, respectively often, the asm data contains pointers that need to have actual symbol names (D_12341234 instead of 0x12341234) so like, figuring those out is not trivial sometimes. they could be the start of a segment, they don't have to be an actual c variable necessarily as for the bin stuff, we need to figure out what the binary data actually is and handle it appropriately. sometimes it's C data, sometimes it's like a custom format for something.

Correct mistaken pointers in c files and data (#277)

this one is tricker. sometimes two symbols have the same value, but one is technically more correct than the other there are times when we DMA an overlay, and one of the things the function call wants is the RAM of the overlay. but instead, we're giving it the first function. which just happens to have the same ram address as the start ram address of the overlay, because it's currently the first thing there. but what happens if we write a function above it? suddenly we're not pointing at the beginning of the overlay anymore but just some random spot in the middle of it these kinds of things are probably going to come up as we start being able to shift here and there, and we'll fix them as we go

Clear undefined_syms

okay so this one is probably the most important atm, and I saved it for last undefined_syms includes all the symbols that are referenced in our asm files and c files but aren't actually declared anywhere the idea is to declare them properly and then remove the entry from undefined_syms a lot of these, if not all, are bss variables. bss vars are weird in that they take up no space in the rom and are at the end of each segment. they're supposed to be defined but not initialized, so like s32 someVar; would presumably end up in BSS all of the BSS vars should be declared in their proper files so we can remove the undefined_syms entry for them however, we can't just get rid of the undefined_syms entry ...for reasons I can explain later. so for now we're throwing all the known bss symbols into main_bss_syms.txt so the work one could do is ...find BSS vars that aren't declared and declare them in the c files that they belong to everything in main_bss_syms is from the first (main) segment, up until like 0x75000 or wheverver it stops. so you could start with those if you wanted

[JoshDuMan]

there are times when we DMA an overlay, and one of the things the function call wants is the RAM of the overlay. but instead, we're giving it the first function.

To be clear, these do not have identical codegen. The former is that of a literal while the latter is a symbol, and this does matter in a variety of situations. Not sure we always have a better way to handle it.

[ethteck]

I don't think that's right @JoshDuMan. The function is a symbol, and the linker symbol for the ram start is also a symbol

[ethteck]

But there are some cases where a constant is wanted, in which case neither of the above will work (if that's what you mean)

[bates64]

@ethteck is correct - both function names and ld_addrs symbols are linker symbols and are resolved at link-time, resulting in different codegen from just writing the address. In all cases where we currently have function names, the ld_addr VRAM symbol will work.

a5dd0 has an example of different codegen w.r.t. ld_addrs.h symbols versus literals:

#ifdef NON_MATCHING
#define AREA_SPECIFIC_ENTITY_VRAM &entity_default_VRAM
#else
#define AREA_SPECIFIC_ENTITY_VRAM 0x802BAE00
#endif

void load_area_specific_entity_data(void) {
    if (D_8015132C == 0) {
        if (gGameStatusPtr->areaID == AREA_JAN || gGameStatusPtr->areaID == AREA_IWA) {
            dma_copy(entity_jan_iwa_ROM_START, entity_jan_iwa_ROM_END, AREA_SPECIFIC_ENTITY_VRAM);
        } else if (gGameStatusPtr->areaID == AREA_SBK || gGameStatusPtr->areaID == AREA_OMO) {
            dma_copy(entity_sbk_omo_ROM_START, entity_sbk_omo_ROM_END, AREA_SPECIFIC_ENTITY_VRAM);
        } else {
            dma_copy(entity_default_ROM_START, entity_default_ROM_END, AREA_SPECIFIC_ENTITY_VRAM);
        }

        D_8015132C = 1;
    }
}