🚀 go-pugleaf

keith@ksmith.uucp (Keith Smith) writes:
>I was under the assumption that the machine model
>of the AS/400 is that everything you scribble on or read from lies
>somewhere on the terabyte or so of address space in the machine.  This
>seems really stupid to me.  Basically then by hiding the hardware in an
>address you would *HAVE* to check the memory references for capability,
>where if you just treated devices differently from the start you can
>avoid this.  

Mapping a file into memory is (to the programmer) like having the
"open" read the entire file into memory. [Modulo issues such as
multiple users opening the file.] This allows a different style of
programming - and  sometimes the style is a better one. That's the
user-level win.

>In fact you avoid 2 layers, the one at the OS level where
>you translate the Device work into a memory reference, and then at the
>microcode level where it gets translated *BACK* to some device
>operation.

Layering can be even worse that that. The file system may use trees
[more generally, "access structures"] to find the pieces of the file
on disk. The virtual memory support uses access structures to map
between file-system-relative locations and addresses. And, a data
base manager or transaction manager does bookkeeping concerning its
pattern of file-relative reads and writes. If these layers ignore
each other, it's possible to get some considerable overheads,
relative to a more integrated product.

[A data base designer tells the story of a user who tried to build a
200 MB data base, and asked why he needed 400 MB free to make it
work.  It turned out that the initialization wasn't special cased,
and was writing all those "new" zeroes into shadow pages, which were
later "committed". The point being that actual usages don't always
match the model the designers worked to.]

-- 
Don		D.C.Lindsay	Carnegie Mellon Computer Science