Happy Birthday VAX 11/780 (influence of)
hilpert at cs.ubc.ca
Sat Oct 30 15:36:50 CDT 2010
On 2010 Oct 30, at 12:34 PM, Dave McGuire wrote:
> On 10/30/10 1:08 PM, Chuck Guzis wrote:
>> 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 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.
> 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.
More information about the cctalk