home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / arch / 9360 < prev    next >
Encoding:
Internet Message Format  |  1992-09-11  |  2.4 KB
  1. Path: sparky!uunet!mcsun!sunic!dkuug!diku!thorinn
  2. From: thorinn@diku.dk (Lars Henrik Mathiesen)
  3. Newsgroups: comp.arch
  4. Subject: Re: trapping speculative ops (LONG)
  5. Message-ID: <1992Sep10.180303.27731@odin.diku.dk>
  6. Date: 10 Sep 92 18:03:03 GMT
  7. References: <1992Aug31.224611.5196@odin.diku.dk> <1992Sep1.143155.636@bcars64a.bnr.ca> <1992Sep9.121701.13208@odin.diku.dk> <1992Sep10.080446.16268@email.tuwien.ac.at>
  8. Sender: thorinn@tyr.diku.dk
  9. Organization: Department of Computer Science, U of Copenhagen
  10. Lines: 41
  11.  
  12. anton@mips.complang.tuwien.ac.at (Anton Martin Ertl) writes:
  13. >thorinn@diku.dk (Lars Henrik Mathiesen) writes:
  14. >|> [...] currently, compilers have no reason to write the same
  15. >|> register twice without intervening reads, [...]
  16.  
  17. >This is true in straight-line code, but generally a write to a
  18. >register is only redundant if *all* possible execution paths that
  19. >execute it write to the register another time before reading it.
  20.  
  21. True --- but I would guess that most such cases have a fair bit of
  22. code between the writes, and so the write-write stall is too rare to
  23. concern the hardware architects. But in an exception-bit architecture,
  24. write-after-write could be almost a paradigm --- speculative
  25. operations can be issued with the ``true'' destination register, and
  26. if they turn out to be ``wrong,'' some other valued is loaded into the
  27. register. Imaginary code for "if (p) p = p->next;":
  28.  
  29.     ; p is in R1
  30.     LD    0(R1),R2    ; start load
  31.     ADD    R1,R0,R0    ; test p
  32.     ADD,EQ    R1,R0,R2    ; override load if p == 0
  33.     ; p is now in R2!
  34.  
  35. >|> [...] trap bits on source operands should not [...] trap, but
  36. >|> should propagate to the result instead.
  37.  
  38. >[...] how do we know which instruction caused the exception? [...] We
  39. >check the trap bit of the original trap-noting instruction. This
  40. >means of course that the compiler has to keep the trap bit alive,
  41. >which restricts register allocation, if the trap bit is associated
  42. >with the destination register.
  43.  
  44. I did not want to clutter up my previous post, but that is exactly
  45. what I had in mind: If the equivalent of exact traps is wanted, the
  46. compiler has to keep every speculatively calculated intermediary alive
  47. until the exception can be taken. This means that the compiler needs/
  48. can utilize more registers than usual, but we're talking about a new
  49. architecture anyway, and I get the impression that registers are cheap
  50. nowadays, or at least not very expensive.
  51.  
  52. Lars Mathiesen (U of Copenhagen CS Dep) <thorinn@diku.dk> (Humour NOT marked)
  53.