Path: utzoo!utgpu!watserv1!watmath!att!rutgers!tut.cis.ohio-state.edu!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!dkuug!freja.diku.dk!njk
From: njk@diku.dk (Niels J|rgen Kruse)
Newsgroups: comp.lang.misc
Subject: Re: Compiler Costs
Message-ID: <1990Jul16.163019.3933@diku.dk>
Date: 16 Jul 90 16:30:19 GMT
References: <1319@fs1.ee.ubc.ca> <56704@lanl.gov> <=AP4-:8@ggpc2.ferranti.com>
Organization: Department Of Computer Science, University Of Copenhagen
Lines: 13

peter@ficc.ferranti.com (Peter da Silva) writes:

}In article <56704@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
}[lookup table]
}> Works just fine (but still slower than the assemble - by a lot) - provided
}> that you are doing parity checking of something _small_, like a single
}> byte.  The table gets kind of large for a 32-bit integer.

}Luckily, parity is conserved. Thus you can use the byte lookup table 4 times
}over the word.

Better yet, xor the bytes together and then use the fine lookup table.
Parity is just the xor of all the bits in any old order, remember.
-- 
Niels J|rgen Kruse 	DIKU Graduate 	njk@diku.dk