"Jerry Avins" <jya@ieee.org> wrote in message
news:w_-dnVdC9_icOtzeRVn-vg@rcn.net...
> rhnlogic@yahoo.com wrote:
>> Randy Yates wrote:
>>
>>>you are to be commended, not denigrated. You have
>>>a viewpoint that spans decades,
>>
>>
>> I certainly don't consider myself an "old-timer" when around
>> those folks, who occasionally speak at the Computer History Museum,
>> who had to design signal processors and real-time computers
>> in the days before there were whole CPUs, DSPs or even memories
>> on single slabs of silicon.
>>
>> http://www.computerhistory.org/
>>
>> It's quite interesting to read about the kinds of problems that
>> were tackled when a single 1-bit adder module was about the size
>> that would contain an entire digital cell phone nowadays.
>
> In college, I solved differential equations with a patch board and these
> gizmos: http://www.national.com/rap/images/DDD1.gif
In my Control Systems class (early 90's), we had an analog computer to play
with. It was kind of neat to play with and so different conceptually from the
digital computers that us kids grew up with (at least for secondary school
portion of our lives).
Reply by Jerry Avins●October 3, 20052005-10-03
rhnlogic@yahoo.com wrote:
> Randy Yates wrote:
>
>>you are to be commended, not denigrated. You have
>>a viewpoint that spans decades,
>
>
> I certainly don't consider myself an "old-timer" when around
> those folks, who occasionally speak at the Computer History Museum,
> who had to design signal processors and real-time computers
> in the days before there were whole CPUs, DSPs or even memories
> on single slabs of silicon.
>
> http://www.computerhistory.org/
>
> It's quite interesting to read about the kinds of problems that
> were tackled when a single 1-bit adder module was about the size
> that would contain an entire digital cell phone nowadays.
In college, I solved differential equations with a patch board and these
gizmos: http://www.national.com/rap/images/DDD1.gif
Jerry
--
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������
Reply by rhnl...@yahoo.com●October 3, 20052005-10-03
Randy Yates wrote:
> you are to be commended, not denigrated. You have
> a viewpoint that spans decades,
I certainly don't consider myself an "old-timer" when around
those folks, who occasionally speak at the Computer History Museum,
who had to design signal processors and real-time computers
in the days before there were whole CPUs, DSPs or even memories
on single slabs of silicon.
http://www.computerhistory.org/
It's quite interesting to read about the kinds of problems that
were tackled when a single 1-bit adder module was about the size
that would contain an entire digital cell phone nowadays.
IMHO. YMMV.
--
rhn A.T nicholson d.O.t C-o-M
Reply by Randy Yates●October 1, 20052005-10-01
"sbhavikb" <sbhavikb@indiatimes.com> writes:
> [...]
> Thank you very much for the suggestion. But my intension to ask the
> question was to have the answer of the division routine in 32 bit. The
> posted routine gives the answer as 64 bit integer which I can not use in
> my program, as there are so many other routines which have to follow the
> division routine and those have to take 32 bit answer of the division
> routine. I tried converting this 64 bit answer in 32 bit but somehow it
> didnt work out. Can you please suggest some way out?
Maybe you could do some analysis yourself? You can't expect things to
be handed to you on a silver platter.
The division of two 32-bit integers requires 64 bits to maintain
precision and avoid overflow if the full range of both input operands
is exercised. If the full range if the inputs are not exercised, or if
the output range is to be limited, then this application-specific
information can be applied to the problem to a) determine how many
bits need to be computed in the division and b) where those bits are
in the full [potential] 64-bit result.
I spent a good amount of time analyzing the division of fixed-pont
numbers in order to understand this. Why shouldn't you?
--
% Randy Yates % "I met someone who looks alot like you,
%% Fuquay-Varina, NC % she does the things you do,
%%% 919-577-9882 % but she is an IBM."
%%%% <yates@ieee.org> % 'Yours Truly, 2095', *Time*, ELO
http://home.earthlink.net/~yatescr
Reply by sbhavikb●October 1, 20052005-10-01
>sbhavikb wrote:
>> >> uint64_t remainder;
>...
>> >> remainder = remainder << 1;
>...
>> Hay, can anyone please give a code for 32 bit fixed point division
which
>> would work for a 32 bit DSP processor. It looks like this code will
not
>> work, as it involves working with a 64 bit integer.
>
>These operations on large unsigned integers can be broken down into
>operations on sets of smaller integers. For instance, a left
>shift on a uint64 can be broken down into shifting two 32-bit integers,
>plus copying the former MSB of one into the resulting LSB of the
>other. See any textbook on binary arithmetic or multi-precision
>arithmetic.
>
>So the earlier posted code will work just fine, with simple
>modifications, not only for 32-bit processors, but for 16-bit and
>8-bit CPU's as well.
>
>And if you want a potentially faster multi-precision integer division
>routine, look into non-restoring algorithms, which can save on some
>comparison cycles.
>
>
>IMHO. YMMV.
>--
>rhn A.T nicholson d.O.t C-o-M
>
>
Hi,
Thank you very much for the suggestion. But my intension to ask the
question was to have the answer of the division routine in 32 bit. The
posted routine gives the answer as 64 bit integer which I can not use in
my program, as there are so many other routines which have to follow the
division routine and those have to take 32 bit answer of the division
routine. I tried converting this 64 bit answer in 32 bit but somehow it
didnt work out. Can you please suggest some way out?
Thank you very much,
Thanks and Regards,
BS
This message was sent using the Comp.DSP web interface on
www.DSPRelated.com
Reply by Randy Yates●September 30, 20052005-09-30
"rhnlogic@yahoo.com" <rhnlogic@yahoo.com> writes:
> Randy Yates wrote:
>> "rhnlogic@yahoo.com" <rhnlogic@yahoo.com> writes:
>> > [...]
>> > So the earlier posted code will work just fine, with simple
>> > modifications, not only for 32-bit processors, but for 16-bit and
>> > 8-bit CPU's as well.
>>
>> Why not perfectly as is? In other words, what portability issues
>> do you see? It seems that as long as we are talking ISO 99 C so
>> that the stdint library is available, we have everything we need.
>
> Guess my age is showing. I worked too many years on systems
> where one could not assume that either the system or the compiler
> and its libraries would transparently support 64-bit operations.
> In fact, in my junior engineer days, I remember having to develop
> library support code for certain *16-bit* arithmetic operations
> (maybe for Z80's and/or 6502's).
The stdint library is a wonderful thing - well overdue in the
language. I've dealing with a fairly large (over a megabyte of object
code) DSP codebase lately with the unfortunate problem of having about
5 different ways (and corresponding include files) to specify integer
types. This is what can happen when such things aren't standardized.
Regarding your age, you are to be commended, not denigrated. You have
a viewpoint that spans decades, and you're still keeping up.
--
% Randy Yates % "Though you ride on the wheels of tomorrow,
%% Fuquay-Varina, NC % you still wander the fields of your
%%% 919-577-9882 % sorrow."
%%%% <yates@ieee.org> % '21st Century Man', *Time*, ELO
http://home.earthlink.net/~yatescr
Reply by rhnl...@yahoo.com●September 30, 20052005-09-30
Randy Yates wrote:
> "rhnlogic@yahoo.com" <rhnlogic@yahoo.com> writes:
> > [...]
> > So the earlier posted code will work just fine, with simple
> > modifications, not only for 32-bit processors, but for 16-bit and
> > 8-bit CPU's as well.
>
> Why not perfectly as is? In other words, what portability issues
> do you see? It seems that as long as we are talking ISO 99 C so
> that the stdint library is available, we have everything we need.
Guess my age is showing. I worked too many years on systems
where one could not assume that either the system or the compiler
and its libraries would transparently support 64-bit operations.
In fact, in my junior engineer days, I remember having to develop
library support code for certain *16-bit* arithmetic operations
(maybe for Z80's and/or 6502's).
Maybe the OP is working on an antique DSP? (More likely, they just
didn't check the C compiler manual...)
IMHO. YMMV.
--
rhn A.T nicholson d.O.t C-o-M
Reply by Randy Yates●September 30, 20052005-09-30
"rhnlogic@yahoo.com" <rhnlogic@yahoo.com> writes:
> [...]
> So the earlier posted code will work just fine, with simple
> modifications, not only for 32-bit processors, but for 16-bit and
> 8-bit CPU's as well.
Why not perfectly as is? In other words, what portability issues
do you see? It seems that as long as we are talking ISO 99 C so
that the stdint library is available, we have everything we need.
--
% Randy Yates % "And all that I can do
%% Fuquay-Varina, NC % is say I'm sorry,
%%% 919-577-9882 % that's the way it goes..."
%%%% <yates@ieee.org> % Getting To The Point', *Balance of Power*, ELO
http://home.earthlink.net/~yatescr
Reply by rhnl...@yahoo.com●September 30, 20052005-09-30
sbhavikb wrote:
> >> uint64_t remainder;
...
> >> remainder = remainder << 1;
...
> Hay, can anyone please give a code for 32 bit fixed point division which
> would work for a 32 bit DSP processor. It looks like this code will not
> work, as it involves working with a 64 bit integer.
These operations on large unsigned integers can be broken down into
operations on sets of smaller integers. For instance, a left
shift on a uint64 can be broken down into shifting two 32-bit integers,
plus copying the former MSB of one into the resulting LSB of the
other. See any textbook on binary arithmetic or multi-precision
arithmetic.
So the earlier posted code will work just fine, with simple
modifications, not only for 32-bit processors, but for 16-bit and
8-bit CPU's as well.
And if you want a potentially faster multi-precision integer division
routine, look into non-restoring algorithms, which can save on some
comparison cycles.
IMHO. YMMV.
--
rhn A.T nicholson d.O.t C-o-M
Reply by sbhavikb●September 30, 20052005-09-30
>>#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;
>>}
>>
>>
>
>Hi Randy,
>Thank you very much for this wonderful code. It minimised my problem to
a
>great extent.
>
>Thanks again,
>
>Regards
>bd.
>
>
>This message was sent using the Comp.DSP web interface on
>www.DSPRelated.com
>
Hay, can anyone please give a code for 32 bit fixed point division which
would work for a 32 bit DSP processor. It looks like this code will not
work, as it involves working with a 64 bit integer.
Thanks and Regards,
SB.
This message was sent using the Comp.DSP web interface on
www.DSPRelated.com