| OLD | NEW |
| (Empty) |
| 1 // Modified by Russ Cox to add "namespace re2". | |
| 2 // Also threw away all but hashword and hashword2. | |
| 3 // http://burtleburtle.net/bob/c/lookup3.c | |
| 4 | |
| 5 /* | |
| 6 ------------------------------------------------------------------------------- | |
| 7 lookup3.c, by Bob Jenkins, May 2006, Public Domain. | |
| 8 | |
| 9 These are functions for producing 32-bit hashes for hash table lookup. | |
| 10 hashword(), hashlittle(), hashlittle2(), hashbig(), mix(), and final() | |
| 11 are externally useful functions. Routines to test the hash are included | |
| 12 if SELF_TEST is defined. You can use this free for any purpose. It's in | |
| 13 the public domain. It has no warranty. | |
| 14 | |
| 15 You probably want to use hashlittle(). hashlittle() and hashbig() | |
| 16 hash byte arrays. hashlittle() is is faster than hashbig() on | |
| 17 little-endian machines. Intel and AMD are little-endian machines. | |
| 18 On second thought, you probably want hashlittle2(), which is identical to | |
| 19 hashlittle() except it returns two 32-bit hashes for the price of one. | |
| 20 You could implement hashbig2() if you wanted but I haven't bothered here. | |
| 21 | |
| 22 If you want to find a hash of, say, exactly 7 integers, do | |
| 23 a = i1; b = i2; c = i3; | |
| 24 mix(a,b,c); | |
| 25 a += i4; b += i5; c += i6; | |
| 26 mix(a,b,c); | |
| 27 a += i7; | |
| 28 final(a,b,c); | |
| 29 then use c as the hash value. If you have a variable length array of | |
| 30 4-byte integers to hash, use hashword(). If you have a byte array (like | |
| 31 a character string), use hashlittle(). If you have several byte arrays, or | |
| 32 a mix of things, see the comments above hashlittle(). | |
| 33 | |
| 34 Why is this so big? I read 12 bytes at a time into 3 4-byte integers, | |
| 35 then mix those integers. This is fast (you can do a lot more thorough | |
| 36 mixing with 12*3 instructions on 3 integers than you can with 3 instructions | |
| 37 on 1 byte), but shoehorning those bytes into integers efficiently is messy. | |
| 38 ------------------------------------------------------------------------------- | |
| 39 */ | |
| 40 | |
| 41 #include "util/util.h" | |
| 42 | |
| 43 #define rot(x,k) (((x)<<(k)) | ((x)>>(32-(k)))) | |
| 44 | |
| 45 /* | |
| 46 ------------------------------------------------------------------------------- | |
| 47 mix -- mix 3 32-bit values reversibly. | |
| 48 | |
| 49 This is reversible, so any information in (a,b,c) before mix() is | |
| 50 still in (a,b,c) after mix(). | |
| 51 | |
| 52 If four pairs of (a,b,c) inputs are run through mix(), or through | |
| 53 mix() in reverse, there are at least 32 bits of the output that | |
| 54 are sometimes the same for one pair and different for another pair. | |
| 55 This was tested for: | |
| 56 * pairs that differed by one bit, by two bits, in any combination | |
| 57 of top bits of (a,b,c), or in any combination of bottom bits of | |
| 58 (a,b,c). | |
| 59 * "differ" is defined as +, -, ^, or ~^. For + and -, I transformed | |
| 60 the output delta to a Gray code (a^(a>>1)) so a string of 1's (as | |
| 61 is commonly produced by subtraction) look like a single 1-bit | |
| 62 difference. | |
| 63 * the base values were pseudorandom, all zero but one bit set, or | |
| 64 all zero plus a counter that starts at zero. | |
| 65 | |
| 66 Some k values for my "a-=c; a^=rot(c,k); c+=b;" arrangement that | |
| 67 satisfy this are | |
| 68 4 6 8 16 19 4 | |
| 69 9 15 3 18 27 15 | |
| 70 14 9 3 7 17 3 | |
| 71 Well, "9 15 3 18 27 15" didn't quite get 32 bits diffing | |
| 72 for "differ" defined as + with a one-bit base and a two-bit delta. I | |
| 73 used http://burtleburtle.net/bob/hash/avalanche.html to choose | |
| 74 the operations, constants, and arrangements of the variables. | |
| 75 | |
| 76 This does not achieve avalanche. There are input bits of (a,b,c) | |
| 77 that fail to affect some output bits of (a,b,c), especially of a. The | |
| 78 most thoroughly mixed value is c, but it doesn't really even achieve | |
| 79 avalanche in c. | |
| 80 | |
| 81 This allows some parallelism. Read-after-writes are good at doubling | |
| 82 the number of bits affected, so the goal of mixing pulls in the opposite | |
| 83 direction as the goal of parallelism. I did what I could. Rotates | |
| 84 seem to cost as much as shifts on every machine I could lay my hands | |
| 85 on, and rotates are much kinder to the top and bottom bits, so I used | |
| 86 rotates. | |
| 87 ------------------------------------------------------------------------------- | |
| 88 */ | |
| 89 #define mix(a,b,c) \ | |
| 90 { \ | |
| 91 a -= c; a ^= rot(c, 4); c += b; \ | |
| 92 b -= a; b ^= rot(a, 6); a += c; \ | |
| 93 c -= b; c ^= rot(b, 8); b += a; \ | |
| 94 a -= c; a ^= rot(c,16); c += b; \ | |
| 95 b -= a; b ^= rot(a,19); a += c; \ | |
| 96 c -= b; c ^= rot(b, 4); b += a; \ | |
| 97 } | |
| 98 | |
| 99 /* | |
| 100 ------------------------------------------------------------------------------- | |
| 101 final -- final mixing of 3 32-bit values (a,b,c) into c | |
| 102 | |
| 103 Pairs of (a,b,c) values differing in only a few bits will usually | |
| 104 produce values of c that look totally different. This was tested for | |
| 105 * pairs that differed by one bit, by two bits, in any combination | |
| 106 of top bits of (a,b,c), or in any combination of bottom bits of | |
| 107 (a,b,c). | |
| 108 * "differ" is defined as +, -, ^, or ~^. For + and -, I transformed | |
| 109 the output delta to a Gray code (a^(a>>1)) so a string of 1's (as | |
| 110 is commonly produced by subtraction) look like a single 1-bit | |
| 111 difference. | |
| 112 * the base values were pseudorandom, all zero but one bit set, or | |
| 113 all zero plus a counter that starts at zero. | |
| 114 | |
| 115 These constants passed: | |
| 116 14 11 25 16 4 14 24 | |
| 117 12 14 25 16 4 14 24 | |
| 118 and these came close: | |
| 119 4 8 15 26 3 22 24 | |
| 120 10 8 15 26 3 22 24 | |
| 121 11 8 15 26 3 22 24 | |
| 122 ------------------------------------------------------------------------------- | |
| 123 */ | |
| 124 #define final(a,b,c) \ | |
| 125 { \ | |
| 126 c ^= b; c -= rot(b,14); \ | |
| 127 a ^= c; a -= rot(c,11); \ | |
| 128 b ^= a; b -= rot(a,25); \ | |
| 129 c ^= b; c -= rot(b,16); \ | |
| 130 a ^= c; a -= rot(c,4); \ | |
| 131 b ^= a; b -= rot(a,14); \ | |
| 132 c ^= b; c -= rot(b,24); \ | |
| 133 } | |
| 134 | |
| 135 namespace re2 { | |
| 136 | |
| 137 /* | |
| 138 -------------------------------------------------------------------- | |
| 139 This works on all machines. To be useful, it requires | |
| 140 -- that the key be an array of uint32_t's, and | |
| 141 -- that the length be the number of uint32_t's in the key | |
| 142 | |
| 143 The function hashword() is identical to hashlittle() on little-endian | |
| 144 machines, and identical to hashbig() on big-endian machines, | |
| 145 except that the length has to be measured in uint32_ts rather than in | |
| 146 bytes. hashlittle() is more complicated than hashword() only because | |
| 147 hashlittle() has to dance around fitting the key bytes into registers. | |
| 148 -------------------------------------------------------------------- | |
| 149 */ | |
| 150 uint32 hashword( | |
| 151 const uint32 *k, /* the key, an array of uint32_t values */ | |
| 152 size_t length, /* the length of the key, in uint32_ts */ | |
| 153 uint32 initval) /* the previous hash, or an arbitrary value */ | |
| 154 { | |
| 155 uint32_t a,b,c; | |
| 156 | |
| 157 /* Set up the internal state */ | |
| 158 a = b = c = 0xdeadbeef + (((uint32_t)length)<<2) + initval; | |
| 159 | |
| 160 /*------------------------------------------------- handle most of the key */ | |
| 161 while (length > 3) | |
| 162 { | |
| 163 a += k[0]; | |
| 164 b += k[1]; | |
| 165 c += k[2]; | |
| 166 mix(a,b,c); | |
| 167 length -= 3; | |
| 168 k += 3; | |
| 169 } | |
| 170 | |
| 171 /*------------------------------------------- handle the last 3 uint32_t's */ | |
| 172 switch(length) /* all the case statements fall through */ | |
| 173 { | |
| 174 case 3 : c+=k[2]; | |
| 175 case 2 : b+=k[1]; | |
| 176 case 1 : a+=k[0]; | |
| 177 final(a,b,c); | |
| 178 case 0: /* case 0: nothing left to add */ | |
| 179 break; | |
| 180 } | |
| 181 /*------------------------------------------------------ report the result */ | |
| 182 return c; | |
| 183 } | |
| 184 | |
| 185 | |
| 186 /* | |
| 187 -------------------------------------------------------------------- | |
| 188 hashword2() -- same as hashword(), but take two seeds and return two | |
| 189 32-bit values. pc and pb must both be nonnull, and *pc and *pb must | |
| 190 both be initialized with seeds. If you pass in (*pb)==0, the output | |
| 191 (*pc) will be the same as the return value from hashword(). | |
| 192 -------------------------------------------------------------------- | |
| 193 */ | |
| 194 void hashword2 ( | |
| 195 const uint32 *k, /* the key, an array of uint32_t values */ | |
| 196 size_t length, /* the length of the key, in uint32_ts */ | |
| 197 uint32 *pc, /* IN: seed OUT: primary hash value */ | |
| 198 uint32 *pb) /* IN: more seed OUT: secondary hash value */ | |
| 199 { | |
| 200 uint32_t a,b,c; | |
| 201 | |
| 202 /* Set up the internal state */ | |
| 203 a = b = c = 0xdeadbeef + ((uint32_t)(length<<2)) + *pc; | |
| 204 c += *pb; | |
| 205 | |
| 206 /*------------------------------------------------- handle most of the key */ | |
| 207 while (length > 3) | |
| 208 { | |
| 209 a += k[0]; | |
| 210 b += k[1]; | |
| 211 c += k[2]; | |
| 212 mix(a,b,c); | |
| 213 length -= 3; | |
| 214 k += 3; | |
| 215 } | |
| 216 | |
| 217 /*------------------------------------------- handle the last 3 uint32_t's */ | |
| 218 switch(length) /* all the case statements fall through */ | |
| 219 { | |
| 220 case 3 : c+=k[2]; | |
| 221 case 2 : b+=k[1]; | |
| 222 case 1 : a+=k[0]; | |
| 223 final(a,b,c); | |
| 224 case 0: /* case 0: nothing left to add */ | |
| 225 break; | |
| 226 } | |
| 227 /*------------------------------------------------------ report the result */ | |
| 228 *pc=c; *pb=b; | |
| 229 } | |
| 230 | |
| 231 } // namespace re2 | |
| OLD | NEW |