home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / arch / 8438 < prev    next >
Encoding:
Text File  |  1992-07-29  |  3.8 KB  |  73 lines
  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!decwrl!adobe!usenet
  3. From: zstern@adobe.com (Zalman Stern)
  4. Subject: Re: Re: What's in a name? (cross-posted to SGI since mentioned)
  5. Message-ID: <1992Jul30.000635.11094@adobe.com>
  6. Sender: usenet@adobe.com (USENET NEWS)
  7. Organization: Adobe Systems Incorporated
  8. References: <58220001@sherpa2.lan1.eldec.com>
  9. Date: Thu, 30 Jul 1992 00:06:35 GMT
  10. Lines: 61
  11.  
  12. In article <58220001@sherpa2.lan1.eldec.com> emagnuso@sherpa2.lan1.eldec.com  
  13. (Erik Magnuson) writes:
  14. [I mention the HP3000->precision architecture and DEC VAX->Alpha  
  15. transitions.] 
  16. [Erik objects to my comparing systems vendors to Intel.]
  17.  
  18. These are interesting examples to see how backwards compatibility can be  
  19. dealt with. Some of the solutions used in these projects apply to the Intel  
  20. architecture. (And in fact, Microsoft is using similar technology in their  
  21. "Virtual DOS Machine" (VDM) for NT.) However my main point is that the  
  22. evolution of the x86 architecture has made bows to backwards compatibility  
  23. which have cost a lot and bought little. Fortunately, Intel has done better  
  24. with the 486 (and probably the 586) as compared to the 286 and 386.
  25.  
  26. > DEC has to support VMS, OSF/1 (aren't they dropping Ultrix?) and (in
  27. > the future) Windows NT. (Two of these are designed to be "portable"
  28. > OS's.)  Systems built around the Intel line have to support MS-DOS, DR
  29. > DOS, Windows, OS/2, Unix, and tens or even hundreds of variations on
  30. > the above most of which are intimately tied to the architecture. Not
  31. > to mention that the price points of the system (and the total units
  32. > shipped) involved are an order of magnitude or two different.
  33.  
  34. In both cases the goal is for *application* binaries to run reliably, with  
  35. acceptable performance and the exact same user interface while supporting  
  36. much better performance and functionality for future applications. In that  
  37. vein, DEC has put significant effort into running Ultrix MIPS binaries on  
  38. Alpha OSF/1 systems. (And apparently, if you believe Microsoft's NT spiel,  
  39. you only need to support the top few thousand applications or so to win.)  
  40. But once again what does this have to do with my point? How much software  
  41. does anybody run in '386 mode on Intel processors? How much of that software  
  42. benefits from having an instruction set closely modeled after the 8086?
  43.  
  44. [My text deleted.]
  45. > I think this is expressed a bit backwards. Many older programs exploit
  46. > "features" of the previous implementations to maximize performance on
  47. > a limited resource machine (i.e. 8088).
  48. A less charitable view is that the 8086 was designed with a lack of  
  49. foresight forcing developers to use such hacks.
  50.  
  51. > These same tricks are often
  52. > not the fastest way to do things on a 486. What's your point? Some
  53. > people will always write for the lowest common denominator and some
  54. > will kill for an additional 10%. (Now where have I heard that before?)
  55. > 
  56. > When Intel want to make existing software run faster, they introduce a
  57. > new part.
  58.  
  59. New versions of the x86 line have not necessarily resulted in the fastest  
  60. way to run MS-DOS programs. At the same time it has been significantly  
  61. difficult for old software to use new architectural features. (I.e. it  
  62. wasn't a matter of changing a few things to gain your speed back.)
  63.  
  64. In other words, if you wanted to run MS-DOS applications fast when the 386  
  65. came out, the fastest 286 around was the best way to do it. If you wanted to  
  66. run a 32 bit OS, you couldn't run MS-DOS programs anyway except for virtual  
  67. 8086 mode. I consider virtual 8086 mode to be a good thing to do. However,  
  68. architecting the 32 bit instruction set to have segment registers, prefix  
  69. instructions, and even more complex addressing modes is bogus.
  70. --
  71. Zalman Stern           zalman@adobe.com            (415) 962 3824
  72. Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
  73.