30 Oct
2010
30 Oct
'10
1:36 p.m.
On 2010 Oct 30, at 12:34 PM, Dave McGuire wrote:
On 10/30/10 1:08 PM, Chuck Guzis wrote:
I remember in the 80's (programming primarily on BSD (and VMS))
thinking it would nice to have that functionality, how easy it would
make a lot of file-access programming, and that it would be easy to add
on a VM system. Of course, I was in ignorance of the prior histories
such as the STAR that Chuck mentions. A few years later a friend would
tell me about the new mmap function in unix.
Aside from expanding program storage, the large
addressing space was
used to map file space (another type of "memory-mapped I/O"), so file
access was actually performed through the paging hardware/software.
That was kind of cool, as the STAR was a memory-to-memory vector
machine, so you could use vector instructions on entire files, rather
than have to issue reads and writes for pieces of a file.
That functionality is in use all over the place today as mmap(),
accessing files as if they were memory, pushing the read/write burden
out into the VM system. It's extremely effective. I'd not consider it to be "memory-mapped
I/O" at all, though, in the
context of "a processor reading and writing I/O ports". Sure, file
I/O is a sort of I/O, and mmap() and similar techniques map that file
I/O into the address space, but the context of this discussion...and
indeed, most, it not all use of the term "memory-mapped I/O" doesn't
refer to this sort of thing.
Well, Chuck did say "a type of". If files are a form of abstracted disk
I/O, then mmap is a form of abstracted memory-mapped I/O.