NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/sys/acorn/8294

Internet Message Format | 1992-08-20 | 5.5 KB

Path: sparky!uunet!stanford.edu!agate!ucbvax!upjomon.usl.com!lithgow
From: [e-mail] (Malcolm Lithgow)
Newsgroups: comp.sys.acorn
Subject: OS differences and improvements (Was Re: new PC's, what's happening acorn?)
Message-ID: <[e-mail]>
Date: 21 Aug 92 00:14:48 GMT
Sender: [e-mail]
Lines: 113

Berkeley still hasn't set up comp-sys-acorn-advocacy -- are they ever
going to?

[In message "Re: new PC's, what's happening acorn?", Joerg Scheurich writes:]
>In article <[e-mail]> [e-mail] (Malcolm Lithgow) writes:
>>Of course, Acorn's UNIX is much more light-weight, but UNIX is simply too
>>heavy for any single-user work. And what advantages does it offer?
>
>1. It supports a orthogonal multitasking:
>   (processes are rather independend from others eg. try to use the
>   change-directory-command in a few taskwindows ...)

The only time I find myself needing a working directory is when I wish to
do a compilation, or some such task. The new DDE allows multiple working
directories -- one per task, in fact, through that new module that also
gives us more-than-256-byte command lines.

>2. virtual memory system:
>   With it you can handle big data very simple, cause the length of your
>   arrays (and programcode itself) is not restricted by the available
>   RAM-memory.

I am rapidly coming to regard OS-level virtual memory as a *disadvantage*
rather than an advantage.

Why? Simply because (a) OS-level virtual memory is very stupid, and slows
down memory accesses enormously, when it is exercised, (b) because having
such VM available encourages programmers to use it, which then exercises
VM, which then slows down your machine.

What is the solution?

I'm not claiming that VM is bad -- it is very useful.  What I am claiming
is that it should not be built in at the OS level, where nothing is known
about the data being manipulated (in conventional OS's, such as UNIX),
and so no optimizations can be made using knowledge of the access
patterns.

To solve this, the development environment(s) for an OS should include
libraries of common data structures (standard arrays, matrices,
associative arrays, tagged tables, lists, stacks, text buffers, draw
buffers, frame buffers, etc.) and these libraries should include
optimized VM code, which can make use of the knowledge of the behaviour
of the data. Also, the compiled code itself should also have its own VM
manager, which can make use of information generated at, or after,
compile time.

Problems you may raise:

This makes the libraries non-portable. Big deal! Look at libc for UNIX,
it is very non-portable already. For a quick port, you could base all
your library code on the array library, and use it's simple (UNIX-style)
VM. For a better port, you get better results.

The several different VM managers take up valuable memory. True, they
each consume memory, but there is no need for them to be very large, and
they should be able to share a lot of code, if written properly. And they
should be shared libraries. I think the trade-off would be worth it.

Proof of concept:

Rob Pike wrote an editor for Plan-9, I believe, called red, or
something.  He spent a lot of time developing a local VM system for this
editor (unecessary, since Plan-9 already has VM), which apparently
improved performance immensely (ie. orders of magnitude, where VM was
involved).

>3. a lot of easy portable, freeware/shareware/Publicdomain software
>   Just a example: did someone ported g++ or mtc to riscos ?

What's mtc? I think you're on a rather shaky limb here. My Arch (with a
20MB) hard disk has the GNU equivalents of all the useful UNIX utilities,
and lots of extra stuff that UNIX doesn't have (such as windowing
spreadsheets, draw packages, etc.). You are terribly misrepresenting the
situation when you pick two of the rare packages that haven't been
ported. (Of course, you could also include such things as mush, or elm,
or less, in that list -- but why bother, since they are things that are
not particularly useful under RISC OS -- has StrongEd been ported to
UNIX?)

>4. Unix become a industrial standart for higher range computers.
>   Compared with UNIX is RISCOS very exotic ...

So what?

Other than the fact that UNIX *has not* become a standard for any type of
computer (have you ever tried to port programs from one version of UNIX
to another, or examined the complexity added to free packages to make
them more portable?), what benefit does UNIX being a standard give you?

If you want to stick to *real* standards then we should all be using MVS,
or VMS for smaller systems (or DOS for unusable systems).

>There are a lot of advantages to have UNIX on every platform (maybe this is
>not true on the Commodore C64 ...)

Yeah? Name one. And don't tell me application portability, because it
isn't an advantage for me, and neither is it much of an advantage for,
say, large businesses, who merely want to transfer their data to the new
system, and are going to have to retrain their employees, anyway (a small
cost compared to their other outlay). And don't say reduced training
costs -- UNIX would *increase* training costs over even a mix of Mac, and
RISC OS (for example).

What the industry should be striving for (and, to my utter disgust,
isn't) is standard data formats between all applications across all
platforms. (Standard communication protocols are, thank goodness, being
addressed.)

UNIX is a nice software development environment. Nothing more. But even
at that I think RISC OS is better.

-Malcolm.  [e-mail]  These are merely my opinions.