home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!mcsun!uknet!axion!rtf.bt.co.uk!duplain
- 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?)
- Message-ID: <1992Aug26.152005.22122@rtf.bt.co.uk>
- Date: 26 Aug 92 15:20:05 GMT
- References: <9208250652.AA04072@ucbvax.Berkeley.EDU>
- Organization: BT Customer Systems, Brighton, UK
- Lines: 221
-
- 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
-