I'm working with Z3 now, and it's been a real joy. One of the biggest advances in programming languages in recent years, perhaps. Glad to see it open-sourced and moved to Github.
For example, a friend and I were playing a board game where each player had hit points, which they represented with two types of cards: type A had "5" on one side and "1" on the other, and type B had a "20" on one side and a "10" on the other. You'd represent your current hitpoints by displaying some number of these cards (out of 6 of the first type and 3 of the second type) face up, and adding up the totals. So, I wanted to find out: what's the smallest hit point value that I can't represent with some combination of cards? The traditional mathematical approach would be generating functions, but that would require at least pencil and paper. With Z3, I execute:
(declare-const a1 Int)
(declare-const a2 Int)
(declare-const a3 Int)
(declare-const a4 Int)
(declare-const a5 Int)
(declare-const a6 Int)
(declare-const b1 Int)
(declare-const b2 Int)
(declare-const b3 Int)
(assert (or (= a1 0) (= a1 1) (= a1 5)))
(assert (or (= a2 0) (= a2 1) (= a2 5)))
(assert (or (= a3 0) (= a3 1) (= a3 5)))
(assert (or (= a4 0) (= a4 1) (= a4 5)))
(assert (or (= a5 0) (= a5 1) (= a5 5)))
(assert (or (= a6 0) (= a6 1) (= a6 5)))
(assert (or (= b1 0) (= b1 10) (= b1 20)))
(assert (or (= b2 0) (= b2 10) (= b2 20)))
(assert (or (= b3 0) (= b3 10) (= b3 20)))
(assert (= (+ a1 a2 a3 a4 a5 a6 b1 b2 b3) i))
(check-sat)))))))
My problem is as follows. I have a microcontroller which runs firmware. I want to verify various things about the hardware+firmware combination. For instance, I may be interested in proving that user mode firmware cannot change the MMU configuration.
There are many parts to this problem. First is verifying that the kernel doesn't expose routines that let you do these kinds of things. This is a kind of s/w verification problem, somewhat well studied. Second, you want to make sure there are no h/w bugs in the microcontroller itself which the user mode software can exploit to do bad stuff. This is traditional h/w verification, also well-studied. The third is that there aren't weird corners of the microcontroller ISA specification itself which can be exploited. This is also a kind of h/w bug albeit a specification bug.
The third part is where Z3 comes in because often, there isn't any specification, and if there is, it's a bunch of PDFs or word documents. What we want is to generate a formal specification, which you can examine using formal tools to prove that it satisfies certain properties. And then we want to prove that our implementation conforms to this specification. We're using some techniques from program synthesis with Z3 as the solver for this.
Check out MS's Code Digger, which uses Z3 as well: http://research.microsoft.com/en-us/projects/codedigger/
I.e. mutate random values for a while, then use an SMT solver to try to find any remaining code paths that haven't been followed by AFL.
I have a feeling AFL would be faster for "simple" paths, but an SMT solver may be handy for getting those last few paths.
There is a whole field of research in program synthesis, much of which can be done efficiently on theorem-provers like Z3. You can read these slides[2] for a good overview.
[1]: http://jelv.is/chlorophyll.pdf
[2]: http://www.cs.berkeley.edu/~bodik/cs294/fa12/Lectures/L1/L1-...
It was tongue-in-cheek, I enjoyed the positivity in your original comment.
One of the more famous places where these constraint solvers are used is to deal with dependency management in package systems. For example, zeroinstall uses a SAT solver to resolve dependency conflicts.
http://0install.net/solver.html
A sillier example is the time I used a sat solver to find the solutions for a flash puzzle game. The part I'm proudest of is that the sat solver could handle the highly symmetric cases that stumped the hand-written backtracking algorithms. And if I had used an SMT solver instead of SAT I would not have had to convert everything all the way doen to boolean formulas.
https://github.com/hugomg/hexiom
In the readme I explain a bit why the sat solver helped.
Would a SAT solver be useful for compiler technologies?
A compiler is basically solving the problem of: here is a sequence of things I want done; here is a description of what the machine can do; find a combination of the latter which achieves the former. The details are the tricky bit, particularly for unpleasantly asymmetric instruction sets like the old 8-bit architectures.
It would be so nice if I could just throw a description of the problem at some sort of machine reasoning system and have it Just Work...
But current SAT solvers aren't powerful enough to do so at much more than a few tens of instructions long. Still useful though.
Perhaps the most relevant example project here would be Rosette[4], which is basically a framework for easily writing synthesizers for different tasks. It would let you implement a description of your machine in Scheme (ie write a simple interpreter) and automatically generate a synthesizer for it that could compile programs in your language to formulas in a solver of some sort.
[1]: http://www.cs.berkeley.edu/~bodik/cs294/fa12/Lectures/L1/L1-...
[2]: http://jelv.is/chlorophyll.pdf
I'm afraid your paper is largely beyond me, though, but I'll go read up on program synthesis. Thanks!