Drop psxMemRLUT, psxMemWLUT

[pcercuei]

Replace accesses to psxMemRLUT and psxMemWLUT with a small inline function psxm().

The reasons behind this change are:

• These were some BIG LUTs. On 32-bit, they would account for 512 KiB of RAM. On 64-bit, they would account for 1 MiB of RAM. This sounds tiny by today's standards, but it still is huge for some of the platforms that PCSX supports.

• Computing the pointer isn't that resource-intensive. Still slower than reading from a LUT (as long as the LUT entry is in the cache, which it should be, as the few valid entries are grouped together), but I doubt that it slows down the interpreter by a lot.

• Even if it does slow down the interpreter a bit, it shouldn't be a huge deal, given that the interpreter isn't really used nowadays as the JITs support all the major CPU architectures, and the interpreter is used mostly for debugging purposes. Besides, the two JITs do not use these LUTs.

[pcercuei]

Bechmarking this on GameCube at the savegame loading screen of Grandia PAL: Before: 16.39 fps After: 14.90 fps

That's a bit worse than I thought. But up to you to see if that's worth it. Alternatively - I can maybe make that configurable at compile time.

[notaz]

I wanted to try this on ARM and it's not working there at all for some reason (games don't boot).

the interpreter isn't really used nowadays

The interpreter is the only option for all Apple platforms (they forbid generated code execution), also wasm/emscripten.

Before: 16.39 fps After: 14.90 fps

Pretty bad considering performance/lower battery usage is the only thing this emu can offer against the "competition".

Alternatively - I can maybe make that configurable at compile time.

More maintenance burden. Unless we gain some new supported platform due to lower mem usage, I'd like to avoid this.

[pcercuei]

More maintenance burden. Unless we gain some new supported platform due to lower mem usage, I'd like to avoid this.

We're hitting RAM limits on GameCube with CHDs.

Making it configurable would be a tiny change in psxm(), I don't really see how it would be a "maintenance burden".

e.g.:

static inline void * psxm(u32 mem, int write)
{
#ifndef DISABLE_MEM_LUTS
    if (write)
        return psxMemWLUT[mem >> 16] + (u16)mem;
    else
        return psxMemRLUT[mem >> 16] + (u16)mem;
#endif

    if (mem >= 0xa0000000)
        mem -= 0xa0000000;
    else
        mem &= ~0x80000000;

    if (mem < 0x800000) {
        if (cache_isolated && !(mem & 0x180000))
            return INVALID_PTR;

        return &psxM[mem & 0x1fffff];
    }

    if (mem > 0x1f800000 && mem <= 0x1f810000)
        return &psxH[mem - 0x1f800000];

    if (!write) {
        if (mem > 0x1fc00000 && mem <= 0x1fc80000)
            return &psxR[mem - 0x1fc00000];

        if (mem > 0x1f000000 && mem <= 0x1f010000)
            return &psxP[mem - 0x1f000000];
    }

    return INVALID_PTR;
}

[notaz]

That doesn't look too bad, yes.

if (cache_isolated && !(mem & 0x180000))

What's this mem check for BTW? It doesn't quite make sense to me.

[pcercuei]

What's this mem check for BTW? It doesn't quite make sense to me.

I got confused with the code in psxMemOnIsolate, it should probably just be if (cache_isolated) return INVALID_PTR; there.

[pcercuei]

@notaz force-pushed, it's a compile-time option now; and the option is disabled by default in the Makefile.

[pcercuei]

Ok, I added a psxm_lut macro that takes the LUT as argument, and fixed the ~0x3 -> ~0xf flag. Also rebased to latest master.