Re: ancient OS history, ARM is sort of channeling the IBM 360

Stephen Fuld wrote:

Lawrence D'Oliveiro wrote:

On Tue, 25 Jun 2024 22:28:40 -0700, Stephen Fuld wrote:
>

But if you are using the "standard" Unix file system, doesn't it
read the block(S) into its cache, then when the user program does
the read, transfer the data from its cache into the user's
variables?  That is the extra overhead to which I was referring.

>
That tends to happen anyway, even on OSes which insist on
record-oriented I/O. For example, on DEC’s VMS, the record blocking
layer is called “RMS” (“Record Management Services”), and that
usually copies records between the user’s buffers and its own
internal buffers (“move mode”). It is possible to request “locate
mode”, where it returns the address of a record directly within its
internal buffers. But there are many restrictions on this, among
other things:
>
* It only works for reads, not for writes
* It doesn’t work for records crossing block boundaries
* It doesn’t work for compressed records
>
So this record-copying overhead is not, in itself, a point against
Unix- style streaming I/O.

The fact that other OSs "made the same mistake"  :-) isn't a point for
treating all I/O as a stream of bytes.  I don't know VAX, but I don't
understand why not for writes.  The no crossing block boundries is a
side effect of fixed block disks.  This couldn't happen in OS/360 with
CKD disks.  I agree about compression, of course, as unless you do the
compression in the I/O hardware stream, you need to "move" the data
anyway.

I had a job at S.E.L where I was assigned the task of reading the
intermediate
representation of the Mary 2 compiler (Ivan's). Out FORTRAN (66+) had
record
oriented I/O that was notoriously slow if you simply wanted stream I/O.
So, after pondering this for a day or two, I wrote up a "streamifier"
a front end to the record oriented FORTRAN I/O. And provided back end
callers essentially a getc() putc() interface to record oriented files.
The system only allowed a use program to have 6 files open at any point
in
time, and since I did not know how man files I might need, I allocated a
20 element file control block structure, which contained the file names
that SW thinks are open, and their current status and point.
Then I build a cache 16-pages of memory and tagged the lines with the
file
identifier,...
When I took a cache miss in the table, I would look through the open
files
list to see if I needed to close one file down and open a different file
up. Perform some I/O requests, and allow caller to munge through
streaming
data.
This SW package would handle large number of virtually open files, and
enable stream level access significantly faster than the record oriented
assembly code file management in the OS. Something like 5× faster--but
it
has been 40 years.