Make no-float policy explicit #684

We don't want floating types for various reasons, e.g.,

• Their representation and often their behavior is implementation-defined.
• Many targets don't support them.

Closes #683.

ACK

ACK bae1bea3c4b46a2fb5ca76ff6bf1e98d43cff52f

After the fact ACK.

One thing to keep in mind WRT benchmarks, is that it's my experience that many embedded developers look at a library and if they see ANY float at all they'll instantly just report up the chain "nope, can't be ported, uses floating point". ... even if that float is some build time optional thing.

[I find they do the same for malloc/free and file I/O too.]

The explicit statement in the readme is probably good enough, but if you encounter this thinking don't be too surprised by it.

One thing to keep in mind WRT benchmarks, is that it's my experience that many embedded developers look at a library and if they see ANY float at all they'll instantly just report up the chain "nope, can't be ported, uses floating point".

This is the only use of double in the bench framework.

src/bench.h:static double gettimedouble(void) {
src/bench.h:void print_number(double x) {
src/bench.h:    double y = x;
src/bench.h:    double min = HUGE_VAL;
src/bench.h:    double sum = 0.0;
src/bench.h:    double max = 0.0;
src/bench.h:        double begin, total;
src/bench.h:        begin = gettimedouble();
src/bench.h:        total = gettimedouble() - begin;

It'd be pretty straightforward to change this to use 64 bit microseconds instead, and get rid of the exception. I might have a stab at it.