a = v ^ 0x30303030lu // normalize to digits 0xXX0a0b0c
b = (a << 12) | a // combine into XXXXXbacb0c
idx = (b >> 12) & 0xfff // get bac
res = lookup[idx]
a = ((a >> 12) | a) & 0xfff
You could also skip the xor with 0x303030 by adjusting the lookup table accordingly.
Unfortunately, you'd still need to factor in the length argument somehow. That is, if given "23" with length=1, it should parse to 2, not 23. You could address this with a variable shift, but at that point, I can't see it being any better than a multiply+shift, even assuming the lookup table is fully cached.
The other major issue is validation, which the lookup table doesn't help much with.
The lookup table can detect some, but not all errors, so yeah, it relies on valid input.
Your code doesn't handle the 'length' parameter, so the problem isn't the highest byte, it's bytes beyond 'length'.
I see what you mean by length. I just skimmed over the text originally as I don't have time for rather lame problems like this. I'd just add 3 bits of length to be part of the index, job done. 12KB lookup table instead of 4KB, assuming 0 is not a valid value (negate to avoid needing 0b11).
It's an interesting idea, but I don't see it being practical, even if the size of the table wasn't an issue.
The comparison here is:
((v ^ 0x303030) * 0x640a0100) >> (len << 3)
against:
table[(((v >> 12) | v) & 0xfff) | (len << 12)]
The former is 4 ops, the latter is 6 ops, so throughput wise, the former wins. Latency wise, it also wins, considering that L1 cache lookups are generally 3-5 cycles, whilst integer multiply is typically 3-4.