Return to the archive index

Re: F.P. on NetWinder WearComp

On Sat, 3 Oct 1998  wrote:
> The real power of a WearComp system is the ability to alter one's visual
> perception of reality, which involves a great many floating point
> calculations.  Also, intelligence signal processing involves floating
> point arithmetic.  Even the Blind Vision project of the 1980s involved
> floating point arithmetic.  Scientific and engineering compuation often
> involves F.P. calculations.

Though future StrongARM processors will have a floating point unit, it can
still be argued that for the majority of applications one is not really
necessary. For most applications (such as searching through that 10MB
database full of names and addresses) floating point is not even
desirable, and for applications which traditionally tend to use real
numbers instead of integers such as image or voice recognition, it is no
real hardship to convert them to use fixed point or even integer math. In
fact on most platforms, doing so will yield an increase in speed and
efficiency (the Pentium processors are somewhat unusual in that using the
FPU, even with the various overheads incurred, often works out faster
than using fixed point integer math).
Just because mathematicians prefer to work with real numbers does not make
it better to use floating point when converting the algorithms into code
(floating point is an inherently inefficient way to do calculations which 
do not need total accuracy such as image or voice recognition).

> Things like word processing can be done on a hand held device, but it is
> the ability to alter the visual perception of reality (e.g. Personal Imaging)
> that sets WearComp apart from carryable devices.  Personal Imaging is
> an application domain where WearComp is required (e.g. it cannot readily
> be done on hand held devices), and in fact, is most likely the
> "killer app" (or "living app") of WearComp.  Thus it is very desirable to
> think about support for F.P. and other abstractions (like complex arithmetic,
> or butterfly operations that can run in hardware with low level
> instructions).

I think I should say that I prefer a more general definition of wearable
computing than yours, but a discussion of that isn't really relevant here.
Let's accept for a moment that you are correct and that the usual task
of a wearable computer will be to take an image, perform various complex
filters on it (including continuously looking up information from various
databases), and then retransmit then it again. Three points:
a. There is definitely nothing there which _has_ to use floating point.
b. There is nothing there for which the speed would necessarily be
made faster by using hardware floating point instead of well written 
integer math.
c. The point is somewhat academic anyway, as the amount of processing
power needed to accomplish this feat is way beyond what could be placed in
a portable platform today. By the time it is possible to accomplish this
processors will have advanced a long way from what we have today, and we
will probably be arguing instead about whether it is better to write code
which is able to be spread across many low end processors, or to take the
easy way out and us one large, high power consumption processor. The kinds
of applications more suited to today's computing power are not so reliant
on floating point (except perhaps for voice recognition, and we do not
have any decent Open Source voice recognition software anyway yet).

> Of course these can be rewritten to use integer computation, and in fact
> integer computation can be rewritten to use binary 1 bit manipulations.

Interesting idea... Hardware adders are so simple though, that I don't
think a uP has ever been made without one (the subtract instruction is, of
course actually a two's complement and an add). Hardware multiply is a
fair bit more complex, especially an advanced type like that in the ARMV8
which is able to perform any multiply in a couple of clock cycles, but
is still nothing compared to the complexity involved in implementing a
hardware floating point processor of a reasonable speed.

> Programming everything in low level binary instructions (e.g. one could
> argue even that integer multiply is not needed, as in the 6502 WearComp
> systems that were programmed in hand assembled machine instructions)
> is possible but more time consuming.

The ratio of processing power gain per area of silicon, power consumption,
and complexity gain for advancing from adding a hardware multiply is far
higher than that gained from adding an FPU.

> High level mathematical abstractions and their actual implementation in
> hardware, however, serve to make the system easier to use and program.

That's a fair argument. It _is_ easier to just use Real data types all the
time and assume that the processor you are using will be able to perform
floating point operations at a reasonable speed than it is to use a fixed
point library instead. That's not to say though that you _can't_ do 
exactly the same things on a high performance non-FP processor such
as the SA110 if you just put a little more effort into coding the
algorithms.

So we come back to "Is the StrongARM a good processor for a wearable
computer?":
Is it an ideal processor for the task? No.
Is any processor? No.
Is it the best processor for the purpose currently available? Possibly.
Is it more suitable than the various x86 derivants? I certainly think so.
Will future StrongARMs be even more suitable? Definitely.

The main benefits of the StrongARM are, of course, their low power
consumption (okay, the NetWinder's a bad example as the peripherals used
in it were intended for desktops, but the PLEB will be a lot better) and
low cost. More important though to most fans of the ARM architecture, like
myself, is that it is just a downright _better_ processor design. I don't
have much knowledge of designs such as MIPS and ALPHA but I do know that
whilst more advanced than the x86 designs, they do have ridiculous power
consumptions. The ARM works by simplifying things (the core is tiny
compared to comparable processors), whereas most modern processor designs
work by simply throwing more and more brute force at the task (oh, just
add a few hundred more KB of L1 cache and stick it on a higher res FAB-
that'll keep the investors happy). A good example of that is the clock
driver in the Alpha processor. It is apparently a 28W fork shaped RF power
transistor which takes up more than 20% of the die area (whilst ARM, on
the other hand, have being performing research into completely
asynchronous processor designs for a number of years). While that may
not be a big problem on a large server connected to the mains supply, it
does rule out their use for such things as cellular phones, PDAs, SCSI
controllers, most embedded systems, satellites, and any sensible design
of wearable computer. Of course, I'm sure you all love lugging 3 Kilos of
lead acid batteries around with you all the time, but I'm not sure the
general public would feel the same way about it :).

Best wishes, Alex.

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------

--
Subcription/unsubscription/info requests: send e-mail with subject of
"subscribe", "unsubscribe", or "info" to 
Wear-Hard Mailing List Archive (searchable): http://wearables.ml.org

From Wear-Hard Mailing list Archive (WH)
Maintained by R. Paul McCarty

Archive created with babymail