Q1.15 calculation
in [DSP]
|
Prev: Kenlighten - A social network for knowledge seekers and providers
Next: help on abs() within matlab
From: Tim Wescott on 9 Jun 2010 18:25 On 06/09/2010 03:22 PM, Raymond Toy wrote: > On 6/9/10 10:33 AM, Tim Wescott wrote: >> >> So generally on an 8- or 16-bit machine the tools will set short and int >> to 16 bits, and long to 32. On a 64-bit machine, everything will be 64 >> bits. > > Did you really mean a 64-bit machine uses 64 bits for short and int and > long? That's not true for every 64-bit machine. Don't most C compilers > for 64-bit machines have 16-bit shorts, 32-bit ints, and 64-bit longs? I was generalizing. Probably most C compilers for 64-bit byte-addressed machines will do it the way you said (plus 8-bit characters). But if it's a 64-bit word-addressed machine, then everything including chars will be 64-bit. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
From: glen herrmannsfeldt on 9 Jun 2010 19:46 Tim Wescott <tim(a)seemywebsite.now> wrote: (snip, someone wrote) >> Did you really mean a 64-bit machine uses 64 bits for short and int and >> long? That's not true for every 64-bit machine. Don't most C compilers >> for 64-bit machines have 16-bit shorts, 32-bit ints, and 64-bit longs? > I was generalizing. Probably most C compilers for 64-bit byte-addressed > machines will do it the way you said (plus 8-bit characters). But if > it's a 64-bit word-addressed machine, then everything including chars > will be 64-bit. I believe that some Cray machines (not currently in production) are 64 bit word addressed. But even that doesn't mean that all the types need to be word sized. There are C compilers for the 36 bit word addressed PDP-10 that use, I believe, 9 bits for char. It is a little tricky, but it can be done. -- glen
From: Tim Wescott on 9 Jun 2010 19:52 On 06/09/2010 04:46 PM, glen herrmannsfeldt wrote: > Tim Wescott<tim(a)seemywebsite.now> wrote: > (snip, someone wrote) > >>> Did you really mean a 64-bit machine uses 64 bits for short and int and >>> long? That's not true for every 64-bit machine. Don't most C compilers >>> for 64-bit machines have 16-bit shorts, 32-bit ints, and 64-bit longs? > >> I was generalizing. Probably most C compilers for 64-bit byte-addressed >> machines will do it the way you said (plus 8-bit characters). But if >> it's a 64-bit word-addressed machine, then everything including chars >> will be 64-bit. > > I believe that some Cray machines (not currently in production) > are 64 bit word addressed. But even that doesn't mean that > all the types need to be word sized. > > There are C compilers for the 36 bit word addressed PDP-10 that > use, I believe, 9 bits for char. It is a little tricky, but > it can be done. It depends on how hard the compiler writer wants to work for it. In C, a pointer has to fit in a long, and it has to be able to point to a unique character. If you want to use a smaller element of storage than what the machine points to natively, you have to kludge up your own pointer representation, and use it _everywhere_, or have a non-compliant compiler. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
From: Randy Yates on 9 Jun 2010 21:26 Tim Wescott <tim(a)seemywebsite.now> writes: > On 06/08/2010 06:58 PM, Randy Yates wrote: >> Tim Wescott<tim(a)seemywebsite.now> writes: >>> [...] >>> Is this C? Do you have to stick to C? C really doesn't like >>> Q1.anything -- it's only native fixed-point data type is integer, and >>> it sticks to it like glue. >> >> Er, all fixed-point processing uses plain integer >> operations. Fixed-point is all in how you interpret things. >> >> There is nothing inherently "non-fixed-point" in C. C is just fine for >> fixed-point processing. > > In most processor instruction sets, multiplying two N-bit registers > coughs up an 2*N bit answer. In most of the rest there's a "multiply > and return high" and a "multiply and return low". In most of the slim > remainder (getting fatter with all the fixed point DSP's out there) > there is some fast way of getting one or the other part -- including > many DSP chips that have a straight "multiply fractional and > accumulate" I've worked on the TI C5x, C55x, C64x, ADI SHARC 21369, and TigerSHARC TS201. I've not seen a "multiply fractional and accumulate" on these. Can you give me an example? Yes, the old Moto 56k did an automatic shift left by one. That's one out of how many? It's not the norm. > or "multiply with shift and accumulate". There is an option on several for automatically shifting right by 1 after multiplying so the result is fractional. Is that what you mean? If so, that's hardly a great reason for avoiding fixed-point in C. I'm the last person in the world that would advocate C over assembly. But in this case, it's usually justified. > C discards the high half, and returns the low. Are you really complaining this hard about having to do an explicit typecast? (See my other post tonight for an example.) > For fractional arithmetic, you want the high half, shifted up one. Big whup. > C is just fine for _integer_ processing, but wastes a lot of steps for > fixed point _fractional_ processing. Maybe one or two, and maybe not even that. It depends on how smart the compiler is, e.g., can it utilize the auto-left-shift mode present in some fixed-point processors. But in any case, I don't call that "a lot." Also, there are many cases (most?) where you are not just doing one multiply and then socking away the result, but rather a series of multiplies. In those cases the extra shift is amortized over the whole block of instructions and is hard worth noting. One thing that *is* rather expensive in fixed-point processing that I've not heard mentioned is saturating. Yes, if you're implementing an equalizer with lots of saturates, shifts, etc., at a high sample rate in a tight inner loop on a small fixed-point DSP with power constraints, yada yada yada, it's going to be worth going to assembly. That's hardly the norm, though. -- Randy Yates % "How's life on earth? Digital Signal Labs % ... What is it worth?" mailto://yates(a)ieee.org % 'Mission (A World Record)', http://www.digitalsignallabs.com % *A New World Record*, ELO
From: Randy Yates on 9 Jun 2010 21:27
Randy Yates <yates(a)ieee.org> writes: > There is an option on several for automatically shifting > right by 1 after multiplying so the result is fractional. > Is that what you mean? Correction: left by 1. -- Randy Yates % "She tells me that she likes me very much, Digital Signal Labs % but when I try to touch, she makes it mailto://yates(a)ieee.org % all too clear." http://www.digitalsignallabs.com % 'Yours Truly, 2095', *Time*, ELO |