Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10    5/3/83; site cornell.UUCP
Path: utzoo!linus!decvax!harpo!floyd!vax135!cornell!hal
From: hal@cornell.UUCP (Hal Perkins)
Newsgroups: net.lang
Subject: Re: I/O operations in programming languages
Message-ID: <5192@cornell.UUCP>
Date: Tue, 30-Aug-83 22:05:39 EDT
Article-I.D.: cornell.5192
Posted: Tue Aug 30 22:05:39 1983
Date-Received: Wed, 31-Aug-83 23:49:27 EDT
References: <1310@tektronix.UUCP>
Organization: Cornell Computer Science
Lines: 58

Bob Dietrich's article arrived while I was posting my previous note.
I'd like to add one thing to what he and Mike Condict have both discussed.

From a logical standpoint, it is very clean to allow Pascal program
parameters to be of any data type.  One can get random-access files
this way very without adding any cruft to the language.  But this
is a bitch to implement on most conventional operating systems.
The representation of random-access files (arrays) on disks and arrays
in main storage, and the operations needed to access elements of these
two different kinds of arrays, are vastly different in almost every
conventional system (including Unix).  So if you try to allow some
program variables and parameters to be associated with disk files and
others to be associated with objects in central storage, you must use
different mechanisms to access the elements of the different sorts of
variables.  This is moderately unpleasant to compile and generate code
for, but for simple variables it's not too bad.  Just keep something in
the symbol table to indicate whether the data is in main store or in the 
file system, and generate the correct code to access it directly or else
call the operating system.

But.... what about parameters to procedures?  Suppose I have two objects
of the same logical data type, one of which is in main store and the
other of which is a program parameter.  And I have a procedure with a
parameter of this type.  What sort of code do I compile in the procedure
to access the parameter?  You really have to use something like the
thunks used to implement ALGOL 60 call-by-name.  And this is a
bad efficiency penalty for access to actual parameters that are
objects in main storage and not in the file system.  Given this
situation, most implementors are not going to go to the trouble of
supporting uniform notations in the language for objects both in main
storage and on the disk, since the compiled code would be too slow for
the "real world", where performance counts.  (I plead guilty to this.
I did a lot of the work on the interface between the Pascal 8000 compiler
and IBM's OS/MVS/CMS systems.  I wanted to implement random files as 
array program parameters, but the implications for code generated for all
array accesses were terrible.)

As long as there are two separate address spaces for main storage and the
filing system as provided on most machines, this problem won't go away.  This
seems to me to be one of the best arguments for the one-level-store concept
(as in Multics, et. seq.), since a one-level store would allow the use of
large variables and data structures in exactly the same way as smaller
data objects (as suggested by Condict) and make it possible to eliminate
the extra baggage needed for files.  A decent abstract data type facility
would allow the definition of trees, indexed data structures, and other
things typically found in file systems.

However, I'm pretty pestimistic that this could be done on most conventional
architectures since it seems that hardware support would be needed for a
decent segmented memory with a very large address space to make the whole
thing work.  I don't see how one can get away from the concept of files and
variables as different sorts of gadgets on most existing machines and
operating systems.

Cheers

Hal Perkins                         UUCP: {decvax|vax135|...}!cornell!hal
Cornell Computer Science            ARPA: hal@cornell  BITNET:  hal@crnlcs