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