Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site cmcl2.UUCP
Path: utzoo!linus!decvax!harpo!floyd!cmcl2!arpaftp
From: arpaftp@cmcl2.UUCP (Arpanet Ftp)
Newsgroups: net.unix-wizards
Subject: Re: Ram disks
Message-ID: <32361@cmcl2.UUCP>
Date: Sat, 6-Aug-83 11:39:54 EDT
Article-I.D.: cmcl2.32361
Posted: Sat Aug  6 11:39:54 1983
Date-Received: Sat, 6-Aug-83 20:38:20 EDT
References: <3598@sri-arpa.UUCP>, <5612@watmath.UUCP>
Organization: New York University
Lines: 76


		Files/Disks Considered Obsolete
		----------- ---------- --------

I cannot understand why so many people seem delighted by the idea of using
RAM as a disk.  It seems a step backwards to me.  RAM is designed to
be accessed very quickly, one word at a time, in a manner that does not
depend on the address of the previous access.  It is much more flexible and
simpler to use than a disk, which must be told all sorts of garbage like
cylinder and track number of the desired data and insists on transferring an
integral number of blocks, whether you need it or not. Consequently hundreds to
thousands of CPU instructions may be executed for each access of a disk (and
up to two system calls).  This is why disk accesses are done by the kernel
while RAM accesses are performed by user programs.
To package a RAM inside of hardware that makes it as complicated to use as a
disk is idiotic in the absence of other constraints (such as no more address
space left to put the RAM on the machine directly).

The only advantage of disks over RAMs is that they can transfer large amounts
of data without the attention of the CPU, except at startup and completion.
If this is the feature that you want, package the RAM inside of hardware that
implements it, but don't make it look like a disk, for Pete's sake.  Or
better yet, switch to a CPU that has an interruptable block-move instruction
(the IBM 370 does, I've been told), which gives you this feature for ALL of
your RAM and allows user programs to perform the accesses with no system calls.
Another alternative is to design a peripheral whose sole function is to copy
blocks of main memory from place to place.  Using DMA, it operates in parallel
with the CPU.  Again this obtains the desired feature for ALL of your RAM and,
better, is faster and does not require changing CPU's.

And as for programs and kernel code (e.g. pipes) that use disk files where,
on a virtual memory system, they should be using virtual memory -- rewrite
them.  A program that is to be portable and needs to manipulate large amounts
of temporary data should encapsulate every access to that data inside functions
and provide (with, say conditional compilation) two versions of those functions:
one that uses program variables and one that uses files, so that the
appropriate choice can easily be made on any system.

There is a better way.  Why not have a programming language feature (analogous
to the *packed* attribute of Pascal) whereby a variable of any type is
declared to be non-time-critical, allowing the compiler to use a disk file
for the variable if deemed useful.  Further, we would allow the programmer
to specify, more strongly, that the variable MUST be allocated on a file, in
which case the name of the file could be given as well.  Assuming the language
has assignment for arbitrary structured data types and has some sort of
non-homogenous sequence data type, it now has no need of explicit file types
and operations.  (And believe it or not Virginia, there are programming
languages that allow the assignment of non-scalar types!)  I proposed this
for Pascal several years ago in SIGPLAN, but nobody was listening (basically
I just argued that the word *file* should be taken to mean *sequence*, not:
*use-a-disk*, and that the word *slow* be prefixed to any type declaration to
indicate that slow mass-storage may be used).  Now, since there are no longer
any files, hence no fd's, standard I/O is accomplished through predefined
sequence variables, e.g. the INPUT and OUTPUT variables, in Pascal.

What I am proposing, then, is to reverse this dangerous, wrong-thinking notion
of using RAMs disguised as disks for /tmp files which should have been RAM
variables anyway (actually, the reverse of the user-level analogue, using files
like variables for reasons not related to the problem):  Let's demand a
programming language where we can use files as flexibly and powerfully as
faster variables.  (I'll design it, if one of you will implement it on Unix.)
I hereby challenge any or all of you to defend the presence of file operations
in a programming language like the one I described, by telling me what you
couldn't do with the *slow* variables that you could do with explicit file
operations.  Please mail responses to me -- I have a sincere research interest
in your opinion.  DO NOT USE the r[eply] command; write to one of:

		...!cmcl2!acf2!condict
		...!decvax!cmcl2!acf2!condict
		...!philabs!cmcl2!acf2!condict

					Michael Condict     (212) 460-7239
					C.I.M.S., New York U.
					251 Mercer St.
					New York, NY    10012