home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / atari / st / 12615 < prev    next >
Encoding:
Internet Message Format  |  1992-08-21  |  3.2 KB
  1. Xref: sparky comp.sys.atari.st:12615 comp.sys.atari.st.tech:4523
  2. Path: sparky!uunet!mcsun!Germany.EU.net!unido!open.de!mailbox!teddy!germany!open!ruhr.de!horga!erni.bs.open.de!lionbbs.bs.open.de!UweKloss
  3. From: UweKloss@lionbbs.bs.open.de ( Uwe Kloss )
  4. Newsgroups: comp.sys.atari.st,comp.sys.atari.st.tech
  5. Subject: Re: Utterly bizarre idea for Atari
  6. Message-ID: <H.ochUJiy12Xc@lionbbs.bs.open.de>
  7. Date: 19 Aug 92 22:38:28 GMT
  8. References: <l90309INN6q5@aludra.usc.edu>
  9.     <1992Aug15.043618.17054@news.csuohio.edu>
  10. Reply-To: UweKloss@lionbbs.bs.open.de
  11. Organization: The Lion Town BBS, Brunswik, Germany
  12. Lines: 64
  13. X-Software: HERMES GUS 1.00 Rev. Jan 16 1992
  14.  
  15. In <l90309INN6q5@aludra.usc.edu>, Juxtaposer writes:
  16.  
  17. >  This sounds like a good idea, except:
  18. > 1)  The 68ks were not built for multiprocessing (big surprise) - you are not
  19. > only talking about totally (almost) re-writing TOS to handle the multiple
  20. > processors (which sounds like a good idea to me anyway), but you would have
  21. > to implement some impressive glue-logic to get the multiple processors to
  22. > work cooperatively since they
  23.  
  24. > a) don't know that they don't own the bus,
  25. Which is definitely wrong!
  26. Even for the simple 68000!
  27. What do you think are the pins ~BR(bus request),
  28. ~BG (bus grant) and ~BGACK (bus grant acknowlege) for?
  29.  
  30. > b) don't understand any kind of memory but super/user,
  31. They understand:
  32.    supervisor program
  33.    supervisor data
  34.    user program
  35.    user data
  36. That can enhance the 16 MB limit (see below) to 64 MB,
  37. but what does that do WRONG????
  38.  
  39. > c) only have 24bits address line
  40. Which means 16 MegaByte and should be enough on a multiprocessor system
  41. where you have, say 8 MB private an 8 MB shared RAM for each processor.
  42. That's 27 * 8(private) + 8(shared) = 224 MB main memory. Not enough?
  43. Boy, your last name is croesus isn't it?
  44.  
  45. > 2) Related to the last point of 1), you really want to have a distributed
  46. > multiprocessor-system - how many times do you run 27 applications simul-
  47. > taneously?
  48. Why? you can split ONE application into several THREADS!
  49.  
  50. > Not to mention that each processor would have to have its own
  51. > memory - and it doesn't sound too appealing or marketable to have to buy
  52. > 27MB so you can have 27 1-MB virtual machines.
  53. Make it upgradeble at least one and at most (as much as you want).
  54. 1MB is much for that task.
  55. Even 8MB (shared) main memory and 128KB (private) cache may be enough
  56. with a hardware supporting virtual memory.
  57.  
  58. > [...] a distributed multiprocessor system, you distribute tasks over the multiple
  59. > would still be going at the original (single processor) speed.
  60. There you address the one and only problem: THE SOFTWARE!
  61. You need a distributed environment!
  62. A parallel OS and parallel Applications which means
  63. parallelising (? ;-) developement tools.
  64.  
  65.    THAT'S THE REAL PROBLEM AT ALL!
  66.  
  67. At least with ATARI! ;-)
  68.  
  69. Uwe
  70. -- 
  71. Eliminiere das Unmoegliche. Was immer uebrig bleibt, so
  72. unwahrscheinlich es auch wirkt, muss die Wahrheit sein.
  73. Aber was ist, wenn einmal NICHTS mehr uebrig bleibt?
  74.    (nach: John Brunner - Mehr Dinge zwischen Himmel und Erde)
  75. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  76. Uwe Kloss                   UUCP: UweKloss@lionbbs.bs.open.de
  77. Fasanenstrasse 65           BTX:  0531336908 0001
  78. 3300 Braunschweig           FIDO: not connected
  79.