paul.mundt at nokia
Oct 31, 2005, 9:44 PM
Post #24 of 31
(4398 views)
Permalink
|
(This is really starting to veer off-topic for this list.. Hopefully
this will clear things up for people still wondering about hard FP)
On Mon, Oct 31, 2005 at 05:32:55PM +0100, Nils Faerber wrote:
> Well, then maybe my experience is limited here.
> I had several ARM based platforms (no ARM9 up to now, admittedly) as
> well as embedded PowerPC and MIPS. None of those had FP and had not
> options for it.
> At least to my experience lets say, hardware FP is uncommon...
>
I'm not sure what your experience is, or what kind of stripped down cores
you were using, but this kind of thing has _always_ been an option for
both embedded PowerPC and MIPS (at least as long as I have been hacking
on them).
With MIPS this kind of thing even goes back to the r2k (almost 2 decades
now, IEEE754 had been ratified in 1985), and has been optionally present
on virtually every major family and individual subtypes since then.
Generally implemented as CP1, where it's trivial to treat the FPUID (I
don't recall the official field designator off the top of my head) very
similar to how PRID parsing is done at runtime. Due to MIPS being fabless
(at least for a lot of its lifetime), I suppose it's quite probable that
whatever vendor you ended up with simply opted to drop this from the
package, however this is hardly the norm.
For embedded PowerPC it's just as common. Both 602 and 603e had it
(although it was only 603e that did double precision, but both were
IEEE754 compliant in hardware) -- this was also over a decade ago, and
people are still using these cores today. The only popular ones that were
lacking it were mpc860/mpc823 and some of the other low-end Motorola
cores (mpc750 had one).
Other embedded platforms (like SH) have even been doing separately
pipelined single-precision vector and matrix operations (128-bit) since
1997, and single/double-precision IEEE754 long before that. Even i960 was
doing hardware FP in those days and earlier.
ARM is really the _only_ architecture where lack of FP hardware is the
norm, rather than the exception. This is slowly starting to change now
with v6 and up supporting VFP (and some ARM9s as well), but I suppose it
will still be an optional component for quite some time, until they get
their implementations worked out. As others have also pointed out, there
are other ARM-based hard macros available with hard FP, besides VFP.
Anyways, let's not misrepresent other embedded architectures due to ARM
being late to the game. Making vague generalizations based on limited
exposure is misleading (even if based on your own experience and with
good intentions), and this will very likely end up confusing other
people. If you are still unsure about this, a few minutes with google
might help to clear things up.
The point remains however, FP of any sort is _not_ the way to go on 1710,
and I hope this is now sufficiently clear to anyone still wondering about
this.
> > An integer based decoder on MPU side would certainly be the most
> > sensible approach.
>
> Sensible in what way?
> Concerning time/effort effectiveness? Then this is probably correct.
Yes.
> Concerning the 770 the DSP based solution should improve device
> performance since the MPU would be left for applications instead of
> decoding.
If someone wants to go to the trouble of writing a DSP codec for OGG
decoding, they're certainly welcome to make a go of it. You can fetch a
toolchain from TI, load up the dspgateway page, and start hacking. I'm
certain Toshihiro-san will welcome any contributions :-)
The integer based decoder is clearly going to outperform any hard FP
based decoder (and most probably soft-float as well). 20% utilization on
MPU isn't that bad of a start though, so as far as time vs effort is
concerned, the integer based MPU way is still the most "approachable"
solution.
|
1
