home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / os / vms / 18362 < prev    next >
Encoding:
Internet Message Format  |  1992-11-23  |  4.7 KB
  1. Path: sparky!uunet!decwrl!pa.dec.com!e2big.mko.dec.com!nntpd.lkg.dec.com!sousa.tay.dec.com!tallis.enet.dec.com!kirk
  2. From: kirk@tallis.enet.dec.com (Matthew B. Kirk)
  3. Newsgroups: comp.os.vms
  4. Subject: Re: Plans for mixed Alpha/VAX cluster with common system disk?
  5. Message-ID: <2261@sousa.tay.dec.com>
  6. Date: 23 Nov 92 20:34:18 GMT
  7. References: <1992Nov20.154517.627@nntpd.lkg.dec.com> <1992Nov20.200412.5852@ais.com>
  8. Sender: kirk@sousa.tay.dec.com
  9. Organization: Digital Equipment Corporation
  10. Lines: 91
  11.  
  12.  
  13. In article <1992Nov20.200412.5852@ais.com>, bruce@ais.com (Bruce C. Wright) writes...
  14. >In article <1992Nov20.154517.627@nntpd.lkg.dec.com>, kirk@tallis.enet.dec.com (Matthew B. Kirk) writes:
  15. >> 
  16. >> In article <1992Nov19.125053.5849@ais.com>, bruce@ais.com (Bruce C. Wright) writes...
  17. >>>What I don't understand is why the image activator in Alpha doesn't
  18. >>>crank up VEST in interpretive mode in such cases (or possibly only if
  19. >>>a flag is set in the image header, like the debug flag).  It seems to
  20. >>>me that this would get you very much of the effect you'd want for
  21. >>>very little penalty (other than the interpretive overhead, of course,
  22. >>>which is substantial but still faster than most VAXen).
  23. >> 
  24. >> VEST is a static translator.  The Translated Image Environment (TIE)
  25. >> contains a fall-back interpreter but it's not particularly fast.              
  26. >> One of the reasons we went to great effort to develop a translator
  27. >> instead of an interpreter (which would have been far simpler) is that
  28. >> interpretation would never have given acceptable performance.  There
  29. >> are too many things that the VAX does (like maintain condition codes
  30. >> all the time) that couldn't be optimized out in interpretation. 
  31. >> Translation allows us to do all sorts of optimization.
  32. > 
  33. >I understand that -- but you can run VEST with the /INTERPRET=ALL
  34. >qualifier, which does interpret the image (at least as I understand
  35. >it).  It just seems to me that it wouldn't have been that difficult
  36. >to do that by default if the image activator encountered a VAX/VMS
  37. >image rather than an Alpha/VMS image, and that it would solve that
  38. >particular problem.  
  39.  
  40. /INTERPRET=ALL is performing a static operation.  (for the uninitiated, 
  41. /INTERPRET=ALL tells VEST to take an OpenVMS VAX image and to 
  42. change the format to be an OpenVMS AXP image.  No code is translated,
  43. so the entire image is interpreted). 
  44.  
  45. This takes time, so for a large image, image activation would take several
  46. minutes.  Alternately, we could just supply an interpreter but as I said
  47. earlier the need to do significant amounts of unnecessary work makes it 
  48. very slow.
  49.  
  50. For example, we would have to maintain all parts of the VAX architecture
  51. ALL THE TIME.
  52.  
  53. >I perfectly agree that it wouldn't set any land
  54. >speed records;  and I think it would still be faster than any but the
  55. >fastest VAX processors around now.
  56.  
  57. Why do you think this?   The only way you could create an interpreter 
  58. that ran this fast (and didn't use on-the-fly translation) would be if 
  59. you were to need only a few Alpha AXP instructions for each VAX instruction.
  60. VEST can do that during translation because it can eliminate unnecessary
  61. steps.    
  62.  
  63. But when you're interpreting an instruction that looks like
  64. "MULL3 (SP)+, (R3), @28(R2)" you have to:
  65.  
  66. 1.  Decode the instruction.   Fairly easy - use a jump table, but this   
  67.     takes several instructions.
  68.  
  69. 2.  Decode the operands.  Operand specifiers are variable length
  70.     and may require multiple memory fetches to decode.  In this case, 
  71.     one memory reference is required to decode the third operand
  72.     specifier.  
  73.  
  74. 3.  Load the operands.
  75.  
  76. 4.  Perform the multiply (1 instruction).
  77.  
  78. 5.  Compute N(egative), Z(ero) and V (overflow) - several instructions.
  79.  
  80. 6.  If an overflow occurred see whether overflows are supposed to be 
  81.     signalled - several instructions to extract the IV (overflow
  82.     enable bit) from the PSL.  
  83.  
  84. 7.  Store results.
  85.  
  86. 8.  Insert the condition code bits in the PSL - a lot of instructions.
  87.  
  88. On top of this, you need to guarantee VAX-style exception behavior and
  89. instruction and memory atomicity all the time since you never know when 
  90. atomicity is or isn't going to be required, and the cost of allowing
  91. this to be switch-selectable at run time in an interpreter is high
  92. (e.g. each time an instruction is interpeted each switch must be checked).
  93.  
  94. How fast do you really think you can make this?  Analysis allows us to 
  95. eliminate step 1 and reduce (or eliminate) steps 2, 3, 5, 6, 7, and 8.
  96.  
  97. =============================================================================
  98. Matthew Kirk                           kirk@tallis.enet.dec.com
  99.  
  100. All opinions expressed here are mine and do not reflect those of Digital
  101. Equipment Corporation.
  102. =============================================================================
  103.