30 Oct
2010
30 Oct
'10
1:54 p.m.
On 30 Oct 2010 at 15:34, Dave McGuire wrote:
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.
I'm sure and I'd never seriously call it "memory-mapped I/O"--but
sometimes our world seems akin to that of Humpty-Dumpty: "When I use
a word it means just what I choose it to mean--neither more nor less"
Uh-oh, here comes another story...
After I left CDC and the STAR project in 1977, my past came back to
haunt me in the form of doing an optimizing FORTRAN for the ETA-10 in
about 1983. We got a leased-line linkup to ETA in St. Paul and I
asked what text editor they were using.
Much to my surprise, it turned out to be the same editor I'd written
for a lark around 1975 when the STAR had lots of really interesting
byte string instructions and I could exploit file-mapped I/O to use
them. Mind you, this was in the day of 16-line 1200 bps terminals.
But the ETA-10 had none of those instructions, essentially having
evolved out of the "everything but the kitchen sink CISC" state of
mind of the original architecture. Some programmer had been detailed
off to replace all of those cool vector instructions with their
scalar equivalents!
I was stunned and opined that with that way of thinking, the software
end of the ETA project was doomed.
--Chuck