You did in a previous post write:

So unless your processor supports IAP where you can reprogram the flash contents from your application (sometimes done by overlapping xdata and code), you will have two tables with constant data.

So if one of the tables is constant and the other table is data received from a serial port, then it's more likely that you have that second table in RAM or in EEPROM, wouldn't you say?

Having the second table in RAM or in CODE doesn't matter much. You still need a loop. And that loop still need to address the specific cell in the specific memory. So you will have to write the required code based on where the tables are, and what assembler instructions that are able to reach these memory cells. You can write a loop with code + data. Or code+code (normally not meaningful). Or xdata+idata. Or whatever combination suits you.

But an even more interesting thing for you to consider - why even store the data from the serial port? You can compare the bytes with your reference table as you receive them. Of you get a mismatch, you can throw away all UART data until the start of a new string. If you get to the end of the string without a mismatch, you are fine.