search for: 96bit

Hi, > The flexibility of this does, though, encourage stuff like 96bit audio. > Anyone implementing a codec which uses this, and import/exports it, will > also write the appropriate conversion OggStream plugin which will allow > applications which only support, say, 16bit audio, to work with it. Do you think the noise in your 16bit application will sound...

...e 128bit vector registers, however, if I am only dealing with 32 bit vector registers, I can add write/read masks that tell the underlying hardware not to work on the whole register, but just a subset of the components. 32bit scalar mov: mov r1.x___, r0.x000 64bit scalar mov: mov r1.xy__, r0.xy00 96bit scalar mov: mov r1.xyz_, r0.xyz0 128bit scalar mov: mov r1, r0 If I had the register type information at code generation time, then I can use the exact same tablegen pattern for all my register types and would only need to add the write/read masks in the printer instead of multiple patterns. Mul...

On Wednesday 24 September 2008 15:23, Mon Ping Wang wrote: > To my knowledge, I don't think there is an easy way to get the MVT > information from a MachineOperand. Why do you need it for? In my See the thread I started on this very topic. Spilling is one place you'd like to have this information. > mind, the MachineInstr and its associated operands represent a >

Arc wrote: > However, support for (ie) 48-bit-float should not have to be created, Where are you going to find a 48 bit float? Is there an IEEE standard for that? I know some floating point DSP chips use a 48 bit float internally, but if there is more than one they are unlikely to be compatible and they certainly cannot be read by standard CPUs without having pull each value apart into

Hi all, Siliva contacted me about this OggPCM proposal and asked me to join in. For those who don't know me, I am the main author and maintainer of libsndfile and therefore know quite a bit about how uncompressed audio is stored in sound files. However even I would not consider myself an expert; there are areas to do with channel assignments that I know I am ignorant of. I am also quite

...prox. 1e-19 volts. This is an excellent argument. It's still not a cap, since spintronics or all sorts of other forms of transferance is possible, but it's not feasable for those to be needed for this revision. Ok so we cap it to 64bit, since much more than that doesn't make sense (96bit would be a "long double" C type) I really don't like this idea, but I will entertain, formatting it as follows: ID Type Bits 0 Int 8 1 uInt 8 2 Int 16 3 Int 24 4 Int 32 5 Float 32 6 Float 64 7 Extended - Unsupported by any v1.0 software This is what I...

...ly not be accessable to any other codec or application unless he writes a conversion plugin, which in essence, treats the two sides (from OggStream's perspective) as two entirely different codecs, even if both are in OggPCM format. The flexibility of this does, though, encourage stuff like 96bit audio. Anyone implementing a codec which uses this, and import/exports it, will also write the appropriate conversion OggStream plugin which will allow applications which only support, say, 16bit audio, to work with it. I guess you could chalk this up to an inherit difference in philosophy an...

Arc wrote: > Ok so we cap it to 64bit, since much more than that doesn't make sense (96bit > would be a "long double" C type) On x86 CPUs, "long double" is 80 bits. > I really don't like this idea, but I will entertain, formatting it as follows: > > ID Type Bits > 0 Int 8 > 1 uInt 8 > 2 Int 16 > 3 Int 24 > 4 Int...