Re: EHP.. Any comments on micro Throughput

Ted Robbins wrote:

> >From: daveland@...
> >
> >Nobody commented on the math Throughput benchmarks I did on the PC
> and a
> microcontroller.
> > I was thinking that someone would show me that high math throughput
> is not
> >required. I know old time CNC had 8080 CPU's and it did this stuff.
> I'm sure
> >floating point math took 100's of us or Milliseconds on those CPU's.
> So I
> guess
> >they used integer math and "picked" some good assumptions for their
> controls.
> >

Yes, I've picked apart the code for an Allen-Bradley 7320, and it
definitely was integer.
They gad a math accelerator board, but it was just to speed multiplies.
I think everything is
based on the single encoder count as the value one.

> Charles Moore, who invented the programming language, "Forth", argues
> that
> floating point math cannot be justified in any application where you
> have
> any information about the range of possible decimal point locations,
> ie;
> "scale".
>
> The cost in speed and accuracy is just too high.

The current high-end CPUs, like Pentums, Alphas, Power PCs, etc. all do
floating point
operations as fast as integer, sometimes even faster, through heavy
pipelining. There are
conceptual advantages in having machines working in rational units like
inches, meters
or mm, for instance. Speed is no longer an issue. Accuracy is lost,
that is true, when very
small and very large numbers must be operated on together. The program
designer
must be aware of these considerations, and make sure they will not cause
trouble.

For instance, adding 1 x 10^-24 to 1.0 on a typical 32-bit float
representation will
equal 1.0, because the smaller number is denormalized to align with the
1.0, and the
significant bit falls off the least significant end. This can cause
real trouble.

Jon