Happy Birthday VAX 11/780 (influence of)

Brent Hilpert 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 mailing list