Reply by Randy Yates January 9, 20062006-01-09
Jerry Avins <jya@ieee.org> writes:
> [...] > He wants it for MPEG, presumably real time.
Still probably not too much of a load on any PC made within the last 10 years. Presuming a 48000 Hz sample rate and 1000 clocks per division, we're up to 48 MHz, or 5 percent of a 1 GHz Pentium.
> It costs little to tell him that if brute force in C is too slow, > there are alternatives. I shouldn't have thrown my bit in on your > watch, as it were.
Maybe I'm misjudging. It seemed to complicate the matter rather than clarify or direct, especially for someone like tommy who is ostensibly naive in algorithms. Please, tell me I'm full-of-it if I'm off base.
> Since Tommy hasn't responded once in this thread -- not even to thank > you [...]
Not that I need thanking, per se, but being polite enough to acknowledge the post would be nice. That's OK, I'm used to it. It seems that many times I don't see a response. I try not to get hung up about it, but it does sorta torque my jaw. -- % Randy Yates % "My Shangri-la has gone away, fading like %% Fuquay-Varina, NC % the Beatles on 'Hey Jude'" %%% 919-577-9882 % %%%% <yates@ieee.org> % 'Shangri-La', *A New World Record*, ELO http://home.earthlink.net/~yatescr
Reply by Jerry Avins January 9, 20062006-01-09
Randy Yates wrote:
>>His application might not tolerate the time it takes, and I >>want him to know that there may well be more efficient ways >>to divide on his computer, and maybe even an algorithm (fraction >>saving?) that avoids the need. > > > He didn't ask for "screamin' 32bit/32bit divide code." If that > isn't what he wanted then he can respond and clarify. > > While "predicting" a person's real need can save time and > post/response cycles in some cases, I find that in general > it isn't wanted or required. > > This is my philosophy. You obvious don't agree, and > that's OK.
He wants it for MPEG, presumably real time. It costs little to tell him that if brute force in C is too slow, there are alternatives. I shouldn't have thrown my bit in on your watch, as it were. Since Tommy hasn't responded once in this thread -- not even to thank you -- we're beyond any real purpose now. Jerry -- Engineering is the art of making what you want from things you can get. &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;
Reply by Randy Yates January 9, 20062006-01-09
> His application might not tolerate the time it takes, and I > want him to know that there may well be more efficient ways > to divide on his computer, and maybe even an algorithm (fraction > saving?) that avoids the need.
He didn't ask for "screamin' 32bit/32bit divide code." If that isn't what he wanted then he can respond and clarify. While "predicting" a person's real need can save time and post/response cycles in some cases, I find that in general it isn't wanted or required. This is my philosophy. You obvious don't agree, and that's OK. --RY
Reply by Randy Yates January 9, 20062006-01-09
Richard, it is good to know there are kindred spirits here. Go in
peace,
brother...   :)

--Brother Randy

Reply by Richard Owlett January 7, 20062006-01-07
Randy Yates wrote:
>[SNIP] > I have been frustrated in the past by folks attempting to > "second-guess" me and I am treating tommy the way I would > like to be treated: to simply answer the question that was > asked. Offering more information is OK too, but first and > foremost, answer the question.
AMEN BROTHER, PREACH IT ;} As a neophyte (I've been scolded for using newbie here) on several groups, I've gotten many replys forcing me to ask the question responder thought I should be asking. A half remembered quote ~"convinced against one's will is still unconvinced" might apply. When beaten down to "accepting" an "answer" nothing actually accomplished as my original question remained unanswered. This group is more tolerant than most. It can have its humorous moments though. One well respected gentleman on another forum and seems to have "form letter" response just for me on certain topics just for me with many many many links. One of those links is to one of his articles that be thinking and then asking the questions which frustrate him ;)
Reply by Jerry Avins January 7, 20062006-01-07
Randy Yates wrote:
> Jerry Avins <jya@ieee.org> writes: > >>[...] >>Repeating from an earlier post on mine in the thread, "You need to >>understand your resources in order to use them well." > > > Yes, that's true. However... > > I don't view the OP as being unclear in his original request. He > asked for a 32-bit division and I gave him one. > > I have been frustrated in the past by folks attempting to > "second-guess" me and I am treating tommy the way I would > like to be treated: to simply answer the question that was > asked. Offering more information is OK too, but first and > foremost, answer the question.
You gave him good cross-platform code, and if he hasn't yet thanked you for it, I'm sure he will. His application might not tolerate the time it takes, and I want him to know that there may well be more efficient ways to divide on his computer, and maybe even an algorithm (fraction saving?) that avoids the need. If you took my comment as a slur on you, I framed it badly. Jerry -- Engineering is the art of making what you want from things you can get. &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;
Reply by Randy Yates January 7, 20062006-01-07
Jerry Avins <jya@ieee.org> writes:
> [...] > Repeating from an earlier post on mine in the thread, "You need to > understand your resources in order to use them well."
Yes, that's true. However... I don't view the OP as being unclear in his original request. He asked for a 32-bit division and I gave him one. I have been frustrated in the past by folks attempting to "second-guess" me and I am treating tommy the way I would like to be treated: to simply answer the question that was asked. Offering more information is OK too, but first and foremost, answer the question. -- % Randy Yates % "Remember the good old 1980's, when %% Fuquay-Varina, NC % things were so uncomplicated?" %%% 919-577-9882 % 'Ticket To The Moon' %%%% <yates@ieee.org> % *Time*, Electric Light Orchestra http://home.earthlink.net/~yatescr
Reply by Jerry Avins January 7, 20062006-01-07
Randy Yates wrote:
> See rules for fixed-point division in > > http://www.digitalsignallabs.com/fp.pdf > > --RY > > #include <stdint.h> > > uint64_t Divide32(uint32_t y, uint32_t x) > { > uint16_t n; > uint64_t answer; > uint64_t remainder; > uint64_t divisor; > > answer = 0; > remainder = x; > divisor = (uint64_t)y << 32; > > for (n = 0; n < 32; n++) > { > divisor = divisor >> 1; > if (remainder >= divisor) > { > remainder -= divisor; > answer |= (uint64_t)1 << (63 - n); > } > } > > for (n = 0; n < 32; n++) > { > remainder = remainder << 1; > if (remainder >= divisor) > { > remainder -= divisor; > answer |= (uint64_t)1 << (31 - n); > } > } > > return answer;
I used to do this in assembly, shifting the quotient into a register a bit at a time as the dividend shifted out of the same register. I could do this on most DSPs, too, but their multipliers make finding the reciprocal and multiplying much more efficient. Repeating from an earlier post on mine in the thread, "You need to understand your resources in order to use them well." Jerry -- Engineering is the art of making what you want from things you can get. &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;
Reply by Randy Yates January 6, 20062006-01-06
"tommy" <parcor@gmail.com> writes:

> Hi users, > I am looking for 32bit/32bit divide code. > Now, I am implementing the PNS random generator for MPEG4 AAC. > I find some divide floating point code in the PNS as followings: > scale = 0x10000000/energy > Of course, energy represents the 32bit fixed point formant. I think two > variables regard as a Q0 format. > Does anybody give me the divide code or explain the theory of integer > divide?
I describe how to perform fixed-point division here: http://www.digitalsignallabs.com/fp.pdf and the routine you seek (for unsigned ints) is here: uint64_t Divide32(uint32_t y, uint32_t x) { uint16_t n; uint64_t answer; uint64_t remainder; uint64_t divisor; answer = 0; remainder = x; divisor = (uint64_t)y << 32; for (n = 0; n < 32; n++) { divisor = divisor >> 1; if (remainder >= divisor) { remainder -= divisor; answer |= (uint64_t)1 << (63 - n); } } for (n = 0; n < 32; n++) { remainder = remainder << 1; if (remainder >= divisor) { remainder -= divisor; answer |= (uint64_t)1 << (31 - n); } } return answer; } -- % Randy Yates % "She's sweet on Wagner-I think she'd die for Beethoven. %% Fuquay-Varina, NC % She love the way Puccini lays down a tune, and %%% 919-577-9882 % Verdi's always creepin' from her room." %%%% <yates@ieee.org> % "Rockaria", *A New World Record*, ELO http://home.earthlink.net/~yatescr
Reply by Randy Yates January 6, 20062006-01-06
See rules for fixed-point division in

  http://www.digitalsignallabs.com/fp.pdf

--RY

#include <stdint.h>

uint64_t Divide32(uint32_t y, uint32_t x)
{
   uint16_t n;
   uint64_t answer;
   uint64_t remainder;
   uint64_t divisor;

   answer = 0;
   remainder = x;
   divisor = (uint64_t)y << 32;

   for (n = 0; n < 32; n++)
   {
      divisor = divisor >> 1;
      if (remainder >= divisor)
      {
         remainder -= divisor;
         answer |= (uint64_t)1 << (63 - n);
      }
   }

   for (n = 0; n < 32; n++)
   {
      remainder = remainder << 1;
      if (remainder >= divisor)
      {
         remainder -= divisor;
         answer |= (uint64_t)1 << (31 - n);
      }
   }

   return answer;