How to quickly find the mismatch pattern in C - c

Question

Pre-condition:
I can't use malloc.
The error will happen within two bytes, means I can search word by word.
My CPU is 32bit ARM11, no OS during this time.
The first two bytes are important, if first two bytes are 0x00, that means all the rest of the bytes should be 0x00.
If first two bytes are 0xFF, all the rest of the bytes should be 0xFF.
If first two byte are not both 0x0000 and 0xFFFF, I just report an error, no need compare the rest.
I read 256Kbyte block data, which should only have two states:
all 0xFF
all 0x00
However, some data may change to a non-predictable value. I need find them out. I can search it one byte by one byte but seems too slow, so I decided to use dichotomy way to do it — which looks like:
divide read out data into equal half, then compare.
if both are not equal to all 0 or F, it means the data is corrupt at both side and I just need to find the earliest one, so I should give up the 2nd part and just divide the first part again. If only one side has problem, just give up the good one and focus on the problematic on.e
loop above idea
seems after 17 time, should find the point.
How to write the code into loop? Do I need 17 different reference static data with different sizes and to use memcmp?
My current code looks like:
unsigned char gReferData1[2] = {0xFF, 0xFF};
unsigned char gReferData2[2] = {0x00, 0x00};
int main(void)
{
int i = 0, result1 = 0, result2 =0;
read_somewhere(readBuff, sizeof(readBuff)); //read out data
//first test first two bytes
result1 = memcmp(gReferData1, readBuff, 2); //test if 0xFFFF
result2 = memcmp(gReferData2, readBuff, 2); //test if 0x0000
if(result1 == 0)
{
// means all rest data should be 0xFF
for(i=2; i<(0x40000/2); i++)
{
result1 = memcmp(gReferData1, readBuff + offet, 2); //test if 0xFFFF
if(result1 != 0)
{
//means find
// do error handle
}
offset+=2;
}
}
else if(result2 == 0)
{
// means all rest data should be 0x00
for(i=2; i<(0x40000/2); i++)
{
result2 = memcmp(gReferData2, readBuff + offet, 2); //test if 0x0000
if(result2 != 0)
{
//means find
// do error handle
}
offset+=2;
}
}
else
{
//just error
// do error handle
}
return 0;
}

Answer 1

In order to find a defect at a random position you will need to examine each byte at least once. There is no algorithm faster than O(n) for this.
However, your proposed algorithm requires to examine each byte more than once. In order to "divide read out data into equal half, then compare", you will have to read every byte. This is what memcmp will do internally: loop through both memory segments from start to finish until there is a discepancy. It isn't magic. It can't do that any more efficiently than you could with a simple loop.
An optimization which might speed this up (test and measure it!) could be to not go through your data-array byte-by-byte but in steps of sizeof(long) and then cast that segment to long before you compare it. This makes use of the fact that on many 32bit CPUs (not all, test and measure it!) it doesn't take more time to compare two 32bit values than it takes to compare two 8bit values.

Answer 2

You need to check that no byte of that buffer has an illegal state, so you have to check each byte at least once.
On most systems, jumping around is expensive, and reading bytes sequentially is less expensive than anything. So I'd use the more sequential reads possible.
One thing you might try to do is to read the whole buffer sequentially and compare each entry with that of the previous entry, "entry" being a byte or a 16, 32, or 64-bit word, depending on which is faster:
DATATYPE previous = *bufptr;
for (i = 1; i < (length of buffer divided by DATATYPE size); i++) {
if (previous != *(bufptr++)) {
break;
}
}
if (i != (length of buffer divided by DATATYPE size)) {
// There has been an error.
}
// Verify that previous is either 0 or the appropriate number of 0xF's.
Another possibility is to run a memcmp() between the first half of the buffer and the second half of the buffer, then (just for the lols) verify that the first byte is indeed either 0x00 or 0xFF. This fails if two bits in the same relative positions in the two halves flip at the same time. How likely is that? It also depends on the hardware (suppose the buffer is two identical chips one over the other, skewered by the same cosmic ray incoming at a perfectly right angle...?).
Depending on the architecture, the compiler and optimizations used, either solution might turn out to be faster; probably not by all that much.