home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / acorn / 8363 < prev    next >
Encoding:
Internet Message Format  |  1992-08-26  |  10.1 KB

  1. Path: sparky!uunet!mcsun!uknet!axion!rtf.bt.co.uk!duplain
  2. From: duplain@rtf.bt.co.uk (Andy Duplain)
  3. Newsgroups: comp.sys.acorn
  4. Subject: Re: OS differences and improvements (Was Re: new PC's, what's happening acorn?)
  5. Message-ID: <1992Aug26.152005.22122@rtf.bt.co.uk>
  6. Date: 26 Aug 92 15:20:05 GMT
  7. References: <9208250652.AA04072@ucbvax.Berkeley.EDU>
  8. Organization: BT Customer Systems, Brighton, UK
  9. Lines: 221
  10.  
  11. In article <9208250652.AA04072@ucbvax.Berkeley.EDU> lithgow@upjomon.usl.com (Malcolm Lithgow) writes:
  12. >
  13. >Don't be silly. You have a rather limited view of what virtual memory
  14. >could be. What's wrong with a VM subsystem that knows patterns of access
  15. >and can say, 'this page is not going to be used for quite a while, and I
  16. >know I'll need some new memory soon, so I'll map this out now, in
  17. >preperation'. (For example.) Tell me how you can get a simple, generic VM
  18. >subsystem doing that! (Even with madvise().)
  19.                              
  20.     [ stuff deleted ]
  21. >
  22. >Tch, tch. You have spent far too long using UNIX. Who says that libraries
  23. >can't access such levels? Just because they can't in UNIX, so what? Is
  24. >the UNIX design philosophy sacred? It isn't for me, I can tell you.
  25. >
  26. >I am quite aware that VM is linked tightly to the hardware. This doesn't
  27. >mean that it can't be stored in 'libraries' that are loaded on demand.
  28. >Even UNIX, realising, after many years, the error of its ways, is heading
  29. >towards this approach. (Not this style of VM, but this style of loadable
  30. >kernel modules.)
  31.  
  32.     [ stuff deleted ]
  33.  
  34. >
  35. >Obviously the OS should contain a simple memory-management unit. This
  36. >system might simply keep track of which pages are available, and which
  37. >are not. When a VM manager starts up a task, it asks for a number of
  38. >pages.  The MM gives it those pages, and the VM manager then uses them.
  39. >Simple.
  40. >
  41. >If not enough pages are available, then the starved VM manager asks the
  42. >other running VM managers if they can spare pages, and they negotiate
  43. >(through a bidding system, probably, see some research done by Xerox),
  44. >resulting in a mutually beneficial arrangement.
  45. >
  46. >There might be extra good bits, such as a notification from the MM to the
  47. >VM managers that extra memory is available.
  48. >
  49. >This doesn't seem too complicated or slow to me, especially when you
  50. >consider the performance improvements you'll be getting.
  51. >             
  52.     [ stuff deleted ]
  53. >
  54. >On the contrary, your dialogue demonstrates that the job of deciding who
  55. >gets pages swapped is a group decision -- the MM simply moderates the
  56. >meeting.
  57. >             
  58.     [ stuff deleted ]
  59. >
  60. >No, I don't think it would happen faster, either. But I don't think it
  61. >would be much slower, and, more importantly, it is only necessary *when
  62. >an object's memory needs change dramatically* (such as at instantiation,
  63. >or destruction). Usually the VM manager can re-use the memory it
  64. >currently has, avoiding the need for negotiations with the other VM
  65. >managers.
  66. >                         
  67.  
  68. >Everything you say harks back to the fact that you are only considering
  69. >VM as its simple form (as used in UNIX). The 'central memory manager' is
  70. >only qualified to decide which pages have been referenced recently and
  71. >swap pages that haven't. If each object type has it's own VM, then that
  72. >VM subsystem can swap out something that has been recently referenced
  73. >that it knows will not be referenced again for a long time, rather than
  74. >stupidly swapping out something that was referenced a long time ago, and
  75. >was about to be referenced again.
  76. >
  77. >Now do you get it?
  78. >
  79. >Of course, the actual swapping code and page manipulation code would
  80. >*not* reside in each VM manager, since it is common to them all, and so
  81. >should probably be put in the common OS (ie. in the MM). RISC OS already
  82. >possesses this level of sophistication.
  83.  
  84.  
  85.     All you seem to be saying is that the user process should have
  86.     more control over what pages get swapped and what pages don't.
  87.     You say that the user process VM manager should be able to do
  88.     this, but you're wrong;  a user process would never be given
  89.     the CPU priviledge to do it, because of security reasons (a multi-
  90.     process operating system would never provide a way for a user
  91.     process to gain this priviledge -- you're just asking for
  92.     trouble).  You also agree that the majority of the code would still
  93.     exist in the kernel, so all you're saying is that a new system call
  94.     should be added to allow the user process to control his virtual
  95.     memory... that is the _only_ way it could be done.  But why do
  96.     you need it ?  One of the principle goals in any operating system
  97.     is to provide the user with a "virtual computer", one where the
  98.     disk, tape, memory etc devices are uniformly addressable. By giving
  99.     the user so much control over the memory system, this "virtual
  100.     interface" is lost.  No virtual memory system is perfect, as it
  101.     takes too much processing time to be so, but I, as a user, would
  102.     rather not have to worry about it; it's the operating systems job.
  103.  
  104.  
  105. >>    Why isn't the UNIX libc portable ? it's mostly written in C! 
  106. >
  107. >That's probably the problem (that it's written in C). ;-/ Seriously, libc
  108. >is quite heavily dependant on byte-ordering, sign-expansion, CPU
  109. >architecture, and compiler vagaries.
  110.  
  111.     And what's your idea of a perfect and portable libc then ?
  112. >
  113. >It does happen on the Arch! What about Richard Loyd's stuff. PlaceIt. All the
  114. >BASIC programs. Etc.                   
  115.  
  116.     It doesn't happen on the same scale.  Basically people write stuff
  117.     and then make it shareware, just like on the PC scene... UNIX
  118.     programmers don't have the same attitude (although it's partly
  119.     because they can't possibly support a binary version of their
  120.     programs on all the UNIX systems available).
  121. >
  122. >Also, perhaps the reduced volume of source-code-included SW is because
  123. >the Arch presents a single platform, rather than a whole range of
  124. >platforms different at both the hardware and OS level?
  125. >
  126. >>Where can I get the source code to !StrongED so I can
  127. >>    port it to UNIX ???
  128. >
  129. >I think StrongED would be rather difficult to port to UNIX. Arch software
  130. >tends to exploit the advantages of the Arch, making it superior but
  131. >difficult to port. What a pity. ;-)            
  132.  
  133.     Well then, why do ask why (in your original message) StrongED hasn't
  134.     been ported to UNIX  ?
  135.  
  136. >
  137. >>Only when the source of a product is made available, can
  138. >>    people be expected to port that product to another OS e.g. the source
  139. >>    to !As was released in comp.acorn.binaries, the same day I ported it
  140. >>    to my SPARCstation... I can now produce AOF files in the superior
  141. >>    development environment :-)
  142. >
  143. >Oh. So that's why Framemaker was ported to other platforms. And Microsoft
  144. >Word. And Novell Netware. And Lotus 1-2-3. Etc. Hmm. Interesting.
  145.  
  146.     I don't understand what you're saying.. is it that the above
  147.     mentioned products where ported to different OS's without using the
  148.     source code from the original product ?  If so then that's extemely
  149.     stupid.
  150.  
  151. >
  152. >Well, the standard for Sun's is either SunOS or Solaris (which are
  153. >incompatible with each other in many ways).
  154. >
  155. >The standard for HP's is HP/UX. (Incompatible with SunOS or Solaris.)
  156. >
  157. >The standard for DEC's is Ultrix. (Incompatible with SunOS, Solaris, or HP/UX.)
  158. >
  159. >The standard for Pyramids is, erm SVR4.0? (Incompatible with SunOS,
  160. >HP/UX, Ultrix, and subtly incompatible with Solaris.)
  161. >
  162. >The standard for IBM's is AIX. (Incompatible with all of the above.)
  163. >
  164. >The standard for PC-AT clones is either SCO, Interactive, or SVR4.0. (All
  165. >incompatible with each other, though SVR4.0 for the PC-AT is source
  166. >compatible with SVR4.0 for any other platform.)
  167. >
  168. >Etc. etc.     
  169.  
  170.     All these above mentioned products are UNIX (they all have licence
  171.     agreements with AT&T/USL to be able to call their products UNIX),
  172.     and that means that all the above mentioned machines have standard
  173.     OS's which are UNIX.
  174.     
  175. >
  176. >It must have been a very simple program, then. Larry Wall's superb perl
  177. >distribution has hundreds or maybe thousands of lines of code for the
  178. >sole purpose of supporting various UNIX systems, and it still didn't
  179. >compile properly on SVR4.0!
  180.  
  181.     Well, I ported the !As assembler that was recently posted to 
  182.     comp.binaries.acorn... that program wasn't what I'd call simple.
  183.  
  184. >
  185. >Don't be silly. Vendor C's product D is capable of reading vendor A's
  186. >product B data format, but makes its own standard, format X. And, vendor
  187. >E's product F is not capable of reading vendor C's format X. Not to
  188. >mention that vendor G's product H is capable of reading everyone's
  189. >format, but can only write it's own, and uses twenty floppies to store
  190. >all the conversion code/data.
  191. >
  192. >Things get very messy very quickly. And for no reason whatsoever.
  193. >               
  194.  
  195. >In fact, if people had a standard data format, they could spend the time
  196. >to port their product to a different OS (such as RISC OS) instead of
  197. >writing millions of converters. ;-)
  198.  
  199.     I can't think of a more boring subject than "standard data formats".
  200.                      
  201.     
  202.     Most of the arguments between you and I in this newsgroup come
  203.     about because you take every opportunity to slag off UNIX whenever
  204.     you can.  You keep trying to compare RISC OS to UNIX when they are
  205.     not in the same league, they are not for the same purpose, and are
  206.     therefore incomparable.  So what if UNIX is written in C and RISC OS
  207.     is written in Assembler ?  The main aspects of an operating system
  208.     should be what they offer by way of services to the user.  UNIX
  209.     offers a uniform interface to the computer hardware, RISC OS doesn't.
  210.     UNIX is used by many computer researchers to implement new systems
  211.     (i.e. the VM system and fast filesystem that Berkeley introduced).
  212.     This can't be done on RISC OS, because (a) the OS source code is
  213.     not distributable or even distributed, (b) it would take too long
  214.     as it is done in assembler.  UNIX is used at many commerical and
  215.     educational establishments to control computers because it offers
  216.     many capabilities.  RISC OS is used by computer hobbyists to
  217.     control their home computers; these people don't need mail systems,
  218.     network    routers, network filesystems, office automation, project
  219.     development environments.
  220.  
  221.     To summarise:
  222.     
  223.         o The two operating systems are different. 
  224.         
  225.         o They are designed to perform different tasks.
  226.  
  227.         o They are not comparable.
  228.                      
  229. -- 
  230. Andy Duplain, BT Customer Systems, Brighton, UK.            duplain@rtf.bt.co.uk
  231. #define    DISCLAIMER      My views and opinions are my own, and not my company's
  232.