"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
32 bit fixed point division
Started by ●September 28, 2005
Reply by ●September 30, 20052005-09-30
Reply by ●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 divisionwhich>> would work for a 32 bit DSP processor. It looks like this code willnot>> 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 ●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 ●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 ●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 ●October 5, 20052005-10-05
"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.gifIn 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).
