Memory mapped I/O

alan canning at
Sun Oct 31 18:01:18 CDT 2010

On Sun, Oct 31, 2010 at 3:47 AM, Johnny Billquist <bqt at> wrote:

> On 2010-10-30 23:18, Brent Hilpert<hilpert at> wrote:
> 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.
> This might very well be totally wrong, but I remember hearing about it at
> the time, that Sun (who I believe was the ones to first implement mmap())
> bascially took the whole TOPS-20 concept and translated it to Unix. A bit
> surprised no TOPS-20 hackers have spoken up yet... This was around for a
> long time on the PDP-10 before this.
> Not sure how it correlates timewise to CDC and the STAR though.
> But no matter if Unix took it from TOPS-20 or not, there is no denying that
> TOPS-20 had this a long time before it came to 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.
> Memory mapped files are kindof neat, but it's not I/O at all in one way.
> After all, all you do is just leave the actual I/O to the virtual memory
> system instead of doing it yourself. So it's not that the I/O is done in any
> different way, it's just initiated by someone else.
>        Johnny
> --
> Johnny Billquist                  || "I'm on a bus
>                                  ||  on a psychedelic trip
> email: bqt at             ||  Reading murder books
> pdp is alive!                     ||  tryin' to stay hip" - B. Idol

At Hughes we did an 8085 FORTH based system with memory mapped I/O in
1979. A block of 256 addresses had an 8741 hanging at each address and an
1802 hanging off of the 8741s. Fun stuff.

Best regards, Steven

More information about the cctalk mailing list