> [...]
> 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.
�����������������������������������������������������������������������

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.
�����������������������������������������������������������������������

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

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.
�����������������������������������������������������������������������

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;