[erlang-questions] A bug? - bloom filters - and loadable BIFs

Mikael Pettersson mikpe@REDACTED
Fri May 1 01:48:35 CEST 2009


Steve Kirsch writes:
 > Wow. That is very cool. And if the bitarray is large enough, it is
 > passed by reference in a message. Awesome.
 > 
 > So is there a way to set a byte or word at a time??

No, and yes.

No, because the bitarray API really is like a plain array API
with the element size being a single bit, so there's no concept
of "multiple elements" in it.

Yes, because HiPE also adds a bytearray API similar to the bitarray
API I've described, and although bitarrays and bytearrays are unrelated
at the API level they happen to have the same representation, so it's
possible to (ab)use bytearray ops on bitarray objects and vice versa.

I'm only mentioning this because you've indicated a willingness to
accepts the caveats of relying on undocumented features. If you do
start using these features you should really have pure Erlang fallbacks
in place if/when these undocumented BIFs change.

 > -----Original Message-----
 > 
 > hipe_bifs:bitarray(NrArrayBits, InitialBitValue) -> BitArray
 > hipe_bifs:bitarray_sub(BitArray, BitNr) -> BitValue
 > hipe_bifs:bitarray_update(BitArray, BitNr, BitValue) -> BitArray
 > 
 > Bit values are the booleans true and false.
 > Array indexing is 0-based (1-based indexing is just sooo wrong).
 > The update operation returns the updated array.
 > 
 > The number of elements in a bit array is limited to what can be
 > described by non-negative fixnums (immediate "small" integers), which is
 > something like 2^27 - 1 on 32-bit machines. Larger bitarrays than that
 > must be emulated using a chunked representation.
 > See lib/hipe/regalloc/hipe_ig.erl for an example (look for the
 > USE_NEW_BITARRAY_BIFS define and the adjset code following it).
 > 
 > /Mikael
 > 



More information about the erlang-questions mailing list