From: duplain@rtf.bt.co.uk (Andy Duplain)
Newsgroups: comp.sys.acorn
Subject: Re: OS differences and improvements (Was Re: new PC's, what's happening acorn?)
Date: 26 Aug 92 15:20:05 GMT
Organization: BT Customer Systems, Brighton, UK

In article <9208250652.AA04072@ucbvax.Berkeley.EDU> lithgow@upjomon.usl.com (Malcolm Lithgow) writes:
>
>Don't be silly. You have a rather limited view of what virtual memory
>could be. What's wrong with a VM subsystem that knows patterns of access
>and can say, 'this page is not going to be used for quite a while, and I
>know I'll need some new memory soon, so I'll map this out now, in
>preperation'. (For example.) Tell me how you can get a simple, generic VM
>subsystem doing that! (Even with madvise().)
			 				
	[ stuff deleted ]
>
>Tch, tch. You have spent far too long using UNIX. Who says that libraries
>can't access such levels? Just because they can't in UNIX, so what? Is
>the UNIX design philosophy sacred? It isn't for me, I can tell you.
>
>I am quite aware that VM is linked tightly to the hardware. This doesn't
>mean that it can't be stored in 'libraries' that are loaded on demand.
>Even UNIX, realising, after many years, the error of its ways, is heading
>towards this approach. (Not this style of VM, but this style of loadable
>kernel modules.)

	[ stuff deleted ]

>
>Obviously the OS should contain a simple memory-management unit. This
>system might simply keep track of which pages are available, and which
>are not. When a VM manager starts up a task, it asks for a number of
>pages.  The MM gives it those pages, and the VM manager then uses them.
>Simple.
>
>If not enough pages are available, then the starved VM manager asks the
>other running VM managers if they can spare pages, and they negotiate
>(through a bidding system, probably, see some research done by Xerox),
>resulting in a mutually beneficial arrangement.
>
>There might be extra good bits, such as a notification from the MM to the
>VM managers that extra memory is available.
>
>This doesn't seem too complicated or slow to me, especially when you
>consider the performance improvements you'll be getting.
>			 
	[ stuff deleted ]
>
>On the contrary, your dialogue demonstrates that the job of deciding who
>gets pages swapped is a group decision -- the MM simply moderates the
>meeting.
>			 
	[ stuff deleted ]
>
>No, I don't think it would happen faster, either. But I don't think it
>would be much slower, and, more importantly, it is only necessary *when
>an object's memory needs change dramatically* (such as at instantiation,
>or destruction). Usually the VM manager can re-use the memory it
>currently has, avoiding the need for negotiations with the other VM
>managers.
>			 		    

>Everything you say harks back to the fact that you are only considering
>VM as its simple form (as used in UNIX). The 'central memory manager' is
>only qualified to decide which pages have been referenced recently and
>swap pages that haven't. If each object type has it's own VM, then that
>VM subsystem can swap out something that has been recently referenced
>that it knows will not be referenced again for a long time, rather than
>stupidly swapping out something that was referenced a long time ago, and
>was about to be referenced again.
>
>Now do you get it?
>
>Of course, the actual swapping code and page manipulation code would
>*not* reside in each VM manager, since it is common to them all, and so
>should probably be put in the common OS (ie. in the MM). RISC OS already
>possesses this level of sophistication.


	All you seem to be saying is that the user process should have
	more control over what pages get swapped and what pages don't.
	You say that the user process VM manager should be able to do
	this, but you're wrong;  a user process would never be given
	the CPU priviledge to do it, because of security reasons (a multi-
	process operating system would never provide a way for a user
	process to gain this priviledge -- you're just asking for
	trouble).  You also agree that the majority of the code would still
	exist in the kernel, so all you're saying is that a new system call
	should be added to allow the user process to control his virtual
	memory... that is the _only_ way it could be done.  But why do
	you need it ?  One of the principle goals in any operating system
	is to provide the user with a "virtual computer", one where the
	disk, tape, memory etc devices are uniformly addressable. By giving
	the user so much control over the memory system, this "virtual
	interface" is lost.  No virtual memory system is perfect, as it
	takes too much processing time to be so, but I, as a user, would
	rather not have to worry about it; it's the operating systems job.


>>	Why isn't the UNIX libc portable ? it's mostly written in C! 
>
>That's probably the problem (that it's written in C). ;-/ Seriously, libc
>is quite heavily dependant on byte-ordering, sign-expansion, CPU
>architecture, and compiler vagaries.

	And what's your idea of a perfect and portable libc then ?
>
>It does happen on the Arch! What about Richard Loyd's stuff. PlaceIt. All the
>BASIC programs. Etc.				   

	It doesn't happen on the same scale.  Basically people write stuff
	and then make it shareware, just like on the PC scene... UNIX
	programmers don't have the same attitude (although it's partly
	because they can't possibly support a binary version of their
	programs on all the UNIX systems available).
>
>Also, perhaps the reduced volume of source-code-included SW is because
>the Arch presents a single platform, rather than a whole range of
>platforms different at both the hardware and OS level?
>
>>Where can I get the source code to !StrongED so I can
>>	port it to UNIX ???
>
>I think StrongED would be rather difficult to port to UNIX. Arch software
>tends to exploit the advantages of the Arch, making it superior but
>difficult to port. What a pity. ;-)		    

	Well then, why do ask why (in your original message) StrongED hasn't
	been ported to UNIX  ?

>
>>Only when the source of a product is made available, can
>>	people be expected to port that product to another OS e.g. the source
>>	to !As was released in comp.acorn.binaries, the same day I ported it
>>	to my SPARCstation... I can now produce AOF files in the superior
>>	development environment :-)
>
>Oh. So that's why Framemaker was ported to other platforms. And Microsoft
>Word. And Novell Netware. And Lotus 1-2-3. Etc. Hmm. Interesting.

	I don't understand what you're saying.. is it that the above
	mentioned products where ported to different OS's without using the
	source code from the original product ?  If so then that's extemely
	stupid.

>
>Well, the standard for Sun's is either SunOS or Solaris (which are
>incompatible with each other in many ways).
>
>The standard for HP's is HP/UX. (Incompatible with SunOS or Solaris.)
>
>The standard for DEC's is Ultrix. (Incompatible with SunOS, Solaris, or HP/UX.)
>
>The standard for Pyramids is, erm SVR4.0? (Incompatible with SunOS,
>HP/UX, Ultrix, and subtly incompatible with Solaris.)
>
>The standard for IBM's is AIX. (Incompatible with all of the above.)
>
>The standard for PC-AT clones is either SCO, Interactive, or SVR4.0. (All
>incompatible with each other, though SVR4.0 for the PC-AT is source
>compatible with SVR4.0 for any other platform.)
>
>Etc. etc.     

	All these above mentioned products are UNIX (they all have licence
	agreements with AT&T/USL to be able to call their products UNIX),
	and that means that all the above mentioned machines have standard
	OS's which are UNIX.
	
>
>It must have been a very simple program, then. Larry Wall's superb perl
>distribution has hundreds or maybe thousands of lines of code for the
>sole purpose of supporting various UNIX systems, and it still didn't
>compile properly on SVR4.0!

	Well, I ported the !As assembler that was recently posted to 
	comp.binaries.acorn... that program wasn't what I'd call simple.

>
>Don't be silly. Vendor C's product D is capable of reading vendor A's
>product B data format, but makes its own standard, format X. And, vendor
>E's product F is not capable of reading vendor C's format X. Not to
>mention that vendor G's product H is capable of reading everyone's
>format, but can only write it's own, and uses twenty floppies to store
>all the conversion code/data.
>
>Things get very messy very quickly. And for no reason whatsoever.
>		       

>In fact, if people had a standard data format, they could spend the time
>to port their product to a different OS (such as RISC OS) instead of
>writing millions of converters. ;-)

	I can't think of a more boring subject than "standard data formats".
				     
	
	Most of the arguments between you and I in this newsgroup come
	about because you take every opportunity to slag off UNIX whenever
	you can.  You keep trying to compare RISC OS to UNIX when they are
	not in the same league, they are not for the same purpose, and are
	therefore incomparable.  So what if UNIX is written in C and RISC OS
	is written in Assembler ?  The main aspects of an operating system
	should be what they offer by way of services to the user.  UNIX
	offers a uniform interface to the computer hardware, RISC OS doesn't.
	UNIX is used by many computer researchers to implement new systems
	(i.e. the VM system and fast filesystem that Berkeley introduced).
	This can't be done on RISC OS, because (a) the OS source code is
	not distributable or even distributed, (b) it would take too long
	as it is done in assembler.  UNIX is used at many commerical and
	educational establishments to control computers because it offers
	many capabilities.  RISC OS is used by computer hobbyists to
	control their home computers; these people don't need mail systems,
	network	routers, network filesystems, office automation, project
	development environments.

	To summarise:
	
		o The two operating systems are different. 
		
		o They are designed to perform different tasks.

		o They are not comparable.
					 
-- 
Andy Duplain, BT Customer Systems, Brighton, UK.            duplain@rtf.bt.co.uk
#define	DISCLAIMER      My views and opinions are my own, and not my company's