31 Oct
2010
31 Oct
'10
4:01 p.m.
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:
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.
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
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
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 softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
the
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.
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.