Memory mapped I/O
scanning.cc at gmail.com
Sun Oct 31 18:01:18 CDT 2010
On Sun, Oct 31, 2010 at 3:47 AM, Johnny Billquist <bqt at softjar.se> wrote:
> On 2010-10-30 23:18, Brent Hilpert<hilpert at cs.ubc.ca> 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
>>>> >> 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,
>>>> >> 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
>>> > 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 Billquist || "I'm on a bus
> || on a psychedelic trip
> email: bqt at softjar.se || 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