Re: using integer audio data
Re: using integer audio data
- Subject: Re: using integer audio data
- From: Ian Ollmann <email@hidden>
- Date: Wed, 22 Aug 2001 00:14:27 -0700
Jeff Moore <email@hidden> wrote
>
on 8/21/01 12:46 PM, Timothy J. Wood <email@hidden> wrote:
>
> Int/float conversions suck on PPC
>
>
I don't know about that. They suck about as much as they do on any
>
processor. Of course with Altivec, you can do it 4 samples at a time with a
>
single instruction and that definitely does not suck.
You can certainly exceed the ability of the memory bus to transfer data
around with the AltiVec unit for this purpose, so that is about as
non-sucky as you can get. Pre-G4 is another story, especially in the
int->float direction where there is no hardware instruction for the
purpose. That ain't fast.
"Timothy J. Wood" <email@hidden> went on to say:
>
Altivec actually (gasp) has an instruction to convert between integer
>
and floating point formats. Sadly, Apple hasn't sold enough G4 machines
>
to replace all the G3s in the field.
Heh. I hope they do soon! It would help if G3s stopped appearing in new
models. Unfortunately, that is beyond the control of anyone likely to be
reading this list.
AltiVec Everywhere(TM)!
>
PPC really needs an instruction that converts an integer to a floating
>
point value in an integer register. It isn't like I'm asking the IU to
>
do FPU ops, just to do a conversion. This would allow you to load the
>
value, convert it and then if you actually wanted to use it, you could
>
store it out and then load it into a FP register.
I wonder if there is a faster way to do it for signed 16 bit ints. If you
look at the code segment presented, the reason there are two stores is
that it is synthesizing a double precision floating point quantity. You
have to do two stores to write out the full 64 bit quantity. That is
unnecessary for a 16 bit int, which can be held in its entirety with
adequate precision in a single precision float. This should save a store
and simplify the store / load sequence and may avoid a problem that
prevents data forwarding if the sizes of the stores and loads are not the
same. The PPC Compiler writers guide (IBM) discusses the general technique
used by Metrowerks. I bet it could be adjusted for single precision FP.
One question before I get into it: do you want to convert -32678...32767
to -32768.0 ... 32767.0 or to -1.0 ... 1.0? I am not familiar with the
floating point format in use by Core Audio since I haven't had a chance to
use it yet. I think there is a chance you could get the scaling factor for
free or nearly free as part of the int->FP conversion by adjusting the
constant used for the exponent. Unfortunately, there is no way to avoid at
some load/store overhead since there is no direct path between those two
units. The shame is that in this case, I think maybe you would like to
just write the result out from the integer unit and not have to load it
into the FPU and store it back out again. That is a bit more challenging.
Ian
---------------------------------------------------
Ian Ollmann, Ph.D. email@hidden
---------------------------------------------------