I've just adjusted memory protection as follows:
First, the base offset of an operand is calculated from ModR/M or immediate operand.
Next, said operand is wrapped against the address size(0xFFFF or 0xFFFFFFFF).
At this point, we have the base offset for a memory operand to read/write from/to(as a byte/word/dword access).
Then, the resulting address(16-bits or 32-bit address) is checked against all two layers of protection/translations. Said checks perform on 64-bit addresses(actually only 17 or 33-bits used, depending on the address size to use).
So for a resulting address byte, only said address is used, which always is within range.
For a 16-bit address, the low byte is always within range. The high byte of the address is checked against address+1 without any wrapping(so offset 0xFFFF+1=0x10000 and 0xFFFFFFFF+1=0x100000000, which will fault against the limit).
FOr a 32-bit address, the low byte is always within range. The high bytes of the address is checked against address+1 to address+3 without any wrapping(so base offset 0xFFFFFFFD+ will result in offsets 0x100000000+, which will fault against the limit).
The limit is either 20-bits(byte granularity) or 32-bits(4K granularity). So anything passing 0xFFFF or limit in 16-bit mode and/or 0xFFFFFFFF or limit in 32-bit mode actually faults using a General Protection fault.
Compared to the earlier method of only using a 32-bit offset in the entire process, wrapping past 0xFFFFFFFF actually faults with 16-bit or 32-bit offsets when used with word/dword offsets(since they are past the segment limit). Earlier, they wouldn't fault because the offset itself including the rest of the operand locations(n+1 or n+1 to n+3) would already wrap to low addresses(so a access at 0xFFFFFFFD would wrap the last byte to 0x00000000 without faulting).
So that's actually having a lot of effect on the whole offset validation, faulting now where it didn't fault properly before(due to wrapping 16-bit or 32-bit addresses). Said wrapping is now only still applied to the actual memory access itself, which only happens when protection validates against the offset or when a CPU doesn't check against the offset(80186(actually accessing offset 0x10000, whereas the 8086 only uses 16-bits with wrapping) or older CPU emulation, since they have no protection).