home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 October / usenetsourcesnewsgroupsinfomagicoctober1994disk1.iso / altsrc / articles / 11217 < prev    next >
Internet Message Format  |  1994-09-05  |  3KB
  1. Path: wupost!waikato!comp.vuw.ac.nz!actrix.gen.nz!hoult!Bruce
  2. Newsgroups: comp.sys.powerpc,comp.arch.arithmetic,gnu.misc.discuss,comp.programming,sci.math,alt.sources
  3. Subject: Re: ANSWER: algorithm to perform 64-bit / 32-bit signed & unsigned divide
  4. Message-ID: <2861579804@hoult.actrix.gen.nz>
  5. From: Bruce@hoult.actrix.gen.nz (Bruce Hoult)
  6. Date: Mon, 5 Sep 1994 03:16:45 +1200 (NZST)
  7. References: <usenet-0209941834550001@lowry.eche.ualberta.ca>
  8. Lines: 44
  9. Xref: wupost comp.sys.powerpc:28530 comp.arch.arithmetic:581 gnu.misc.discuss:18434 comp.programming:12169 sci.math:76349 alt.sources:11217
  10.  
  11. usenet@lowry.eche.ualberta.ca (Brian Lowry) writes:
  12. > > dmult   ;
  13. > >         MulLW   R6,R3,R4                ; Generate low word of result
  14. > >         StW     R6,4(R5)                ; Save result
  15. > >         MulHWU  R7,R3,R4                ; Generate high word of result
  16. > >         StW     R7,0(R5)                ; Save result
  17. > >         BLR                             ; Return to caller
  18. > 
  19. >   This code makes me curious about PPC assembly (I've read the manual and
  20. > a book on it, but I guess the details don't stick until you write some
  21. > code).  I would have thought that there would be some way to get the 64bit
  22. > value to an FP register and then write it out to memory, thus saving a
  23. > very expensive extra memory write operation.  Also, everything I know
  24. > about pipelining suggests that reorganizing the code as
  25.  
  26. No.  Unfortunately there is no way to get information between the integer and
  27. FP registers without going through memory (cache).
  28.  
  29. Overall, this is a good tradeoff, because you don't really want to do it all
  30. that often, and having the two units totally separate makes it simpler to
  31. push the clock rate up, making the machine overall faster.
  32.  
  33.  
  34. > MulLW   R6,R3,R4                ; Generate low word of result
  35. > MulHWU  R7,R3,R4                ; Generate high word of result
  36. > StW     R6,4(R5)                ; Save result
  37. > StW     R7,0(R5)                ; Save result
  38. > 
  39. > would be more efficient.  If anyone can spare the time to clue me in on
  40. > the finer points of PPC assembly, I'd appreciate it (not that I mind
  41. > programming in C/C++, but occasionally it seems somewhat inefficient...)
  42.  
  43. You'd think so, but unfortunately on the PPC601 the integer mul instructions
  44. aren't pipelined and they stall the next instruction until they have
  45. completed.
  46.  
  47. If a future PPC chip has either a) pipelined integer mul, or b) two or more
  48. integer ALUs capable of doing muls at the same time, then you would be
  49. correct.
  50.  
  51. I'd tend to write it your way anyway, since even on the PPC601 it won't be
  52. worse than the original, and it might one day be better.
  53.  
  54. -- Bruce
  55.