home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / compiler / 2064 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  2.6 KB
  1. Xref: sparky comp.compilers:2064 comp.arch:11863
  2. Newsgroups: comp.compilers,comp.arch
  3. Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!gatech!news.byu.edu!eff!world!iecc!compilers-sender
  4. From: Andre.Marien@cs.kuleuven.ac.be (Andre Marien)
  5. Subject: Sun sparc behavior
  6. Reply-To: Andre.Marien@cs.kuleuven.ac.be (Andre Marien)
  7. Organization: Dept. Computerwetenschappen K.U.Leuven
  8. Date: Tue, 22 Dec 1992 11:00:50 GMT
  9. Approved: compilers@iecc.cambridge.ma.us
  10. Message-ID: <92-12-095@comp.compilers>
  11. Keywords: sparc, architecture
  12. Sender: compilers-sender@iecc.cambridge.ma.us
  13. Lines: 41
  14.  
  15. While trying to get some ideas for optimization, we run into some oddities
  16. which we cannot explain. We have no solid background in architecture, but
  17. would like to have some explanation for the observed behavior.  Our
  18. test frame should have all data and instructions in the cache.  (compare
  19. loop with NN nops with loop where N nops are replaced).
  20.  
  21. First, any store takes 5 cycles on a sparc 1, and 7 cycles on a sparc 2
  22. server.  Is this number related to the pipeline depth ?  Why is it that
  23. stores take at least 5 cycles, even if the surrounding code is just
  24. no-ops?
  25.  
  26. Our guesses:
  27. 1) the pipeline is emptied for some reason.
  28. 2) The cache can only deliver on datum at the time, so it cannot deliver
  29.    both an instruction and data.
  30.    As reading takes 2 cycles on all sparcs tested, it is not unreasonable
  31.    for us for the store to take 3 cycles. But 5 ??
  32.  
  33. Second, two consecutive stores add 2 cycles. Two consecutive loads add no
  34. cycle.  This seems to imply that despite the fixed cost, the write
  35. buffer(s) is not available in time.  However, three stores after each
  36. ather only incur these 2 extra cycles once !?  On the sparc 2 server, it
  37. looks as if the distance between two stores should be odd to avoid those 2
  38. cycles. We think it may have to do with the pipeline organization, but
  39. have no clue.
  40.  
  41. Third, on the sparc 2 server, we notice that a load + store takes 7
  42. cycles, not 9, independent of whether we store to the location of the load
  43. or not.  The same is true for the combination store + load. Putting some
  44. noops between the load/store or store/load increases the number of cycles
  45. just by that number.How can an independent load make a store go faster ??
  46.  
  47. If any kind soul can give some feed-back or references, we would be happy.
  48. We know we don't need the architecture definition, but some docs on the
  49. implementation. Some clues we obviously missed would already be very nice.
  50.  
  51. Andre' Marien
  52. bimandre@cs.kuleuven.ac.be
  53. -- 
  54. Send compilers articles to compilers@iecc.cambridge.ma.us or
  55. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  56.