home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / arch / 9311 < prev    next >
Encoding:
Internet Message Format  |  1992-09-08  |  2.1 KB
  1. Path: sparky!uunet!gatech!purdue!sample.eng.ohio-state.edu!cis.ohio-state.edu!news.sei.cmu.edu!firth
  2. From: firth@sei.cmu.edu (Robert Firth)
  3. Newsgroups: comp.arch
  4. Subject: Re: SPARC Floating Point Query
  5. Message-ID: <1992Sep9.171204.24907@sei.cmu.edu>
  6. Date: 9 Sep 92 17:12:04 GMT
  7. References: <1992Sep9.135913.12073@gdr.bath.ac.uk>
  8. Organization: Software Engineering Institute
  9. Lines: 51
  10.  
  11. In article <1992Sep9.135913.12073@gdr.bath.ac.uk> masjpf@gdr.bath.ac.uk (J P Fitch) writes:
  12. >Can anyone throw any light on the following aspect of the SPARC?
  13.  
  14.     fdivd    %f0,%f2,%f4        <<< Note well
  15.  
  16. **    fmovs    %f4,%f4        ** added by Assembler
  17.  
  18.     fdtoi    %f4,%f5
  19.     st    %f5,[%sp+LP12]
  20.  
  21. [a heap of monstrously bloated and stupendously bad generated code
  22.  deleted, since I don't want to see it again and I'm sure you don't]
  23.  
  24. I suspect the answer is to be found in the Sparc Architecture manual,
  25. section C.6, which deals with the issues of floating point execution.
  26. The processor can execute one or more Fp ops concurrently, which raises
  27. the issue of when this is safe.  The spec I have seems to be wrong, ie
  28. it does not accurately describe the behaviour of the machine, but what
  29. *seems* to be the case [Warning - I may be wrong!] is that
  30.  
  31.     if an FP op is executing, that uses a register %fx, and
  32.     a new FP instruction is fetched, that makes a conflicting
  33.     use of %fx, then the new instruction will be delayed until
  34.     the earlier completes, IF the new instrcution is a load,
  35.     store, or move (plus some special cases not germane).
  36.  
  37. Thus, these are safe:
  38.  
  39.     fadd %f0,%f2,%f2
  40.     ld   [src],%f0        ; will delay until fadd no longer needs %f0
  41.  
  42.     fadd %f0,%f2,%f4
  43.     st   %f4,[dest]        ; will delay until fadd writes to %f4
  44.  
  45. But this is unsafe:
  46.  
  47.     fdivd %f0,%f2,%f4
  48.     fdtoi %f4,%f5
  49.  
  50. since the second instruction is allowed to start before the first completes.
  51.  
  52. The assembler seems to be solving this problem by inserting a dummy move:
  53.  
  54.     fdivd %f0,%f2,%f4
  55.     fmovs %f4,%f4
  56.  
  57. to force completion of the divide.  Whether this is necessary depends on
  58. how many instructions your FPU can execute concurrenyly - if that number
  59. is one, you can get away without the fmov.
  60.  
  61. Sigh.  sunt lacrimae rerum.
  62.