oddball functions of two bits

[presidentbyamendment]

## Rick presidentbyamendment Hohensee 2019
# generate a checksum using only Boolean functions of two bits not
# typically available on a standard CPU ALU

# Poorly used stuff bugs me. The US Capitol building, for example.
# Another example, there are functions of two bits that aren't
# usually used that might be useful to add fast simple variety to
# checksum algorithms.

## There are 16 possible functions of 2 input bits. Only
## 10 are effected by both inputs. There's also zero, one,
## A, B, NOT A, and NOT B, which are effectively unary, or
## no-ary in the case of zero and one. I don't expect
## them to be useful in a checksum algorithm. The others
## are effected by both inputs. Exclusive OR and NOT
## Exclusive OR have a 50% bit result likelihood. The
## others come in pairs of one and three result bits in
## the truth table, such as AND and NOT AND.

## The ones you don't see as outputs on a standard ALU that also
## provides arithmatic are JustA, JustB, NOTJustA, and NOtJustB.
## That's what I call them. Proper docs call JustB "B&~A" I guess,
## which is kinda how we emulate them in Bash. They usually
## replace those with arithmatic functions in hardware ALUs. I use
## the four of them in sequence to give bit propagation balance of
## 50% and some positional distinction. Each cycle is a
## Boolean and a count test, at any data width.

# So what's wrong with XOR? Nothing. I just think the
# oddballs give some added variety very inexpensively.
# That seems to be a good thing in checksums.

#IF your 2 bit Boolean fn chart looks like this...

#A B
#0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1
#0 1 0 0 0 0 1 1 1 1 0 0 0 0 1 1 1 1
#1 0 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1
#1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
# 0 2 4 11 13 15


# the minterms I'm going to use are 2, 4, 11 and 13. My
# scribbles indicate that if you use them in that sequence
# on a stream of zero bits the result will oscillate
# between a zero and one result with a 50% or 25% ON rate
# (duty cycle) depending on if fn 13 thinks the
# accumulator is input A or input B.


JA () { # second minterm, just A
let CS=$CS\&~$1
}

JB () { # fourth minterm, just B
let CS=$1\&~$CS
}

NJA () { # eleventh minterm, NOT just A
let CS=$CS\&~$1
let CS=~$CS
}

NJB (){ # thirteenth minterm NOT just B
let CS=$1\&~$CS
let CS=~$CS
}

# processing binary data from files in Bash is worse than merely
# sticking binary data in files in Bash, so we'll just pretend.
# Presume a CS variable, checksum. We will deform all arguments
# to dadef, data deformer, into CS. Args to dadef can be 64 bit
# ints in decimal or 0x hex, or I suppose, 0octal .

dadef () {
let seq=0
for k in $*
do
let foo=$seq%4
case $foo in

0)
JA $k
;;

1)
JB $k
;;

2)
NJA $k
;;

3)
NJB $k
;;
esac
echo $seq " " $CS
let seq+=1
done
}

#So do :: dadef 393458934 34945345 934529345 and then echo $CS