🚀 go-pugleaf

In article <2850@sdcsvax.UCSD.EDU> bagwill@decuac.DEC.COM (Bob Bagwill) writes:
>Some people call RAM "fast memory" and disk "slow memory" (and tape
>"very slow memory").  With large address spaces and virtual memory, who
>needs files?  Why not define all storage as extended memory structures
>that may be loaded as needed.  ...

This is a great idea.  In fact, it's such a great idea that it was first
implemented in the late 1960s under Multics, which indeed does all of its
file I/O by mapping the files into the address space.  The IBM System/38
also has a single-level-store architecture, with all memory and file objects
having a uniform addressing scheme.  Even the RT PC was supposed to do its
file I/O through the pager, but we kind of wimped out.  It seems to me that
considerable performance gains should be obtained this way, because the path
from the program to the I/O supervisor via page faults should be faster than
that through system calls -- no user arguments to validate.

There are some problems with doing I/O this way, most notably that it makes
device independence very hard.  How do you do I/O to a terminal through page
faults?  To a network socket?  Beats me.  For that matter, how do you tell
how big a file is to less than the granularity of a page?  You add extra
system calls which lose much of the elegance that page-fault I/O gains.

The other reason that you want files is that they have an existence and a
naming structure separate from the programs that manipulate them, which is
kind of unavoidable.  You as a human would probaby rather call a file
/usr/fred/games/source/pinball_bounce.c, while your program would rather
have a nice handle like a memory address of 0x18723d70 or a file handle of 5.

-- 
John R. Levine, Javelin Software Corp., Cambridge MA +1 617 494 1400
{ ihnp4 | decvax | cbosgd | harvard | yale }!ima!johnl, Levine@YALE.something

Where is Richard Nixon now that we need him?

[He's 76 years old, hopefully he a relaxing -DL]