feature request for adding bitwise operators in jit.gen and jit.expr

I was just wondering why there is no support for bitwise operators when writing expressions with jit.expr or inside jit.gen?

You can work around this with arithmetic, but it can get tedious real fast, especially when considering the normalization behavior of jit.expr and jit.gen (more on this later).

Say you want to do bit-packing with jit.matrices. we can easily do this with normal jit.op objects like, jit.&, jit.|, jit.^, jit.~, jit.<<, jit.>>
&: bitwise and;
|: bitwise or;
^: bitwise xor;
~: bitwise compliment (unary);
>>: right shift;
<<: left shift

While the jit.expr reference states: "The expression can contain any operator available from within jit.op" - this just doesn't seem to be the case, not sure if I've missed something? Or if it uses different syntax? Can't find anything in the documentation regardless.

Now regarding the normalization behavior of these objects, it would be nice to be able to turn this off, if possible, for instance when you are working with char matrices.
Here's what I am referring to:

(Getting back to bit-packing)
I want to store variable "A" as 1bit int, and variable "B" as 7bit int, within the 8bit char matrix "C".
we can do this to pack bits:
C = (B<<7)+A
(and this to unpack):
A = C&127
B = C>>7

This is trivial enough with max objects, or jit.op, but when doing it with jit.expr or jit.gen, we first have to use arithmetic which should be less efficient than bitwise? We also have to counter their normalization like so:
in[0]%128
- wont work, since char matrices passed have values normalized to 0. - 1. internally in jit.expr

so we do this instead:
in[0]%(128/255)
- sort of works but now precision is off, unless we set the jit.expr object to float64 (more memory overhead for larger matrices)

finally this works, and hence my (hopefully polite) complaint about the tediousness of these objects :-)
(in[0]*255%128)/255
- ie multiplying char matrices by 255, then doing integer arithmetic, then dividing by 255 again before output, since jit.expr likes to do its own scaling already.

obviously this would look a lot better:
in[0]&127
vs this
(in[0]*255%128)/255

• especially when working on larger projects, where multiple jit.op objects chained together might not be ideal.

hopefully I'm not the only one who would like to see the introduction of bitwise operators in these cases.

- Regards
Svend/Gus