29 Oct
2010
29 Oct
'10
12:14 p.m.
On 2010-10-29 19:00, "Chuck Guzis"<cclist at sydex.com> wrote:
On 29 Oct 2010 at 0:11, Johnny Billquist wrote:
I think that virtual address space is intimately connected to virtual
memory, and you cannot have one without the other.
If your program vrites data to address 0, and reads it back, and get the
same data back, and another program on the same machine, at roughly the
same time, write to address 0, and reads the same data back, and that
data is different than the first programs data, then I'd say you have
virtual memory.
Next question: Does the VAX not have virtual
memory any more now that
I've pointed this out? Or do you need to redefine virtual memory in
yet a new and strange way to exclude the PDP-11... :-D
I think that using memory address spaces to qualify the "virtualness"
of memory is following the wrong animal. I would define "virtual memory" as the
ability to fool a program into
thinking that it has more physical memory than is actually present.
So, can a PDP-11 with 16K of memory appear to a program as if there
were 32K present?
Certainly. If we just disregard that the code needed to implement this
thing might need more memory than 8K. The program that we intend to fool
must have atleast 8K of physical memory, to which we can read in and out
pages. With 16K that would leave just 8K for out demand paging software...
Well, actually, this is a bit too simplified. An instruction can
potentially refer to 4 pages, so we would need to be able to have four
pages to be able to fully fool a program. That would mean minimum 32K of
physical memory to use for the user program. And then some for your
kernel. But you'd probably be able to come in under 56K, while fooling
the program that is has 64K. With less than four pages, you could get
into a situation where mapping in one page means you have to map out
another, which the instruction refers to, and when you restart the
program you'll just get another page fault, ad infinitum... :-)
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
30 Oct
30 Oct
10:08 a.m.
On 29 Oct 2010 at 21:14, Johnny Billquist wrote:
If your program vrites data to address 0, and reads it
back, and get
the same data back, and another program on the same machine, at
roughly the same time, write to address 0, and reads the same data
back, and that data is different than the first programs data, then
I'd say you have virtual memory.
So, your definition ties virtual memory into multi-user access?
That's not the way I learned it.
Consider (again folks, I'm sorry for the reference) the CDC 6600
(circa 1964). Every user is given a relocation address (called RA)
and field length (FL) as a way of partitioning main memory. Each
user's memory addressing space is kept isolated from every other's
and this fits your definiton because one user's location X was
different from every other user's location X and there was no way for
a user to tell what his RA was; i.e. each user was safely "boxed in".
That's not virtual memory by any stretch of the definition. Over-
committing memory meant writing/reading the entire FL of a user to
disk ("rollout" and "rollin").
Now consider the STAR-100 (I think it would qualify as the first
virtual memory machine of CDC), circa 1969. Every user got an
addressing space of 48 bits, but the machine itself had only
512Kwords (64 bit) of physical storage. For production use, most of
the time the system was run in single-user mode (kept thrashing down
with large data sets). That fits my definition of VM because the
user was fooled into thinking that there was more physical memory
than there really was.
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.
So I think we differ considerably in our definitions.
--Chuck
12:34 p.m.
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'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.
-Dave
--
Dave McGuire
Port Charlotte, FL
1:36 p.m.
On 2010 Oct 30, at 12:34 PM, Dave McGuire wrote:
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 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.
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
31 Oct
31 Oct
6:21 a.m.
Chuck Guzis wrote:
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"
Each adjective and noun can often mean many different things to
individuals with different
backgrounds. The other day I had an interesting discussion concerning
the words "never"
and "always". While my definition for each word is 0% and 100%,
respectively, it soon
became apparent that "never" might, in some circumstances include up to
10% and "always"
might be as low as 90%, depending on the context. DoubleSpeak seems to
be easy for
many individuals where being precise is not very important.
Fortunately, as a programmer,
I learned very early to appreciate the lack of redundancy in any
language used for code
with a computer. Or maybe that should be "UNFORTUNATELY".
Uh-oh, here comes another story...
After I left CDC and the STAR project in 1977, my past came back to
Interesting!! I worked for CDC in Toronto from around 1972 to 1977 on
the local PL-50
program. IIRC, the PL-50 was a much slower version of the STAR-100, but
with the
same instruction set. Initially, the goal was to write an operating system.
However, after almost 35 years, I probably don't have any STAR-100
manuals around. If
I do, they are probably buried in the mountain of old documentation.
Chuck, do you have
any of the manuals around for the instruction set. Might there be such
a manual on bitsavers?
For reasons that are best forgotten, when the project was cancelled just
short of being
finished, I ended up attempting to tidy up some of the loose ends. I
also made a
comparison with the the IBM virtual memory and ran some code on both the
PL-50
and the IBM 370 (?? is that the correct IBM model around 1975?) to
compare the
efficiency of the paging algorithm on each machine.
One rather interesting aspect of the paging algorithm on the STAR-100
made use of the
hardware stack of pages which was kept in an LRU (Least Recently Used)
order in a List
in memory. When the number of available pages (either completely free
or unaltered) fell
below the accepted threshold, the MOST LRU altered page was written to
its disk backup
in anticipation that that page would be the MOST LRU when the time came
to discard that
page from physical memory. In order to test the size of the threshold,
statistics were kept
on how often that page was altered again (which meant that the disk I/O
operation had not
been very useful. Throughput was significantly increased since the
required new page (at
a different virtual address) could be read immediately without having
the double wait time
due to writing out an altered MOST LRU page before the replacement page
could be
read.
Jerome Fine
10:54 a.m.
New subject: CDC STAR was: Happy Birthday VAX 11/780 (influence of)
On 31 Oct 2010 at 8:21, Jerome H. Fine wrote:
Interesting!! I worked for CDC in Toronto from around
1972 to 1977 on
the local PL-50 program. IIRC, the PL-50 was a much slower version of
the STAR-100, but with the same instruction set. Initially, the goal
was to write an operating system.
I was part of the Sunnyvale mafia and worked with quite a number of
your Canadian co-workers. Anil and I later partnered up on the
FORTRAN compiler for the ETA-10. You probably remember that the PL-
50/STAR-65 met an unfortunate fate at the hands of the corporate
"leave nothing behind" people. I witnessed firsthand, the
destruction of the two STAR-1B systems a couple of years later. It
wasn't pretty--a dumpster, bolt cutters and large hammers. I saved a
heatsink from the power supply--there wasn't much else left intact.
I begged to be allowed to take the ROS stack from one system, but no
such luck. The stations were removed and sent back to Arden Hills.
--
I'm going from memory on this one, but there's some STAR literature
on bitsavers if you want to check my facts.
256 registers of 64 bits; if halfword mode was selected, the lower
128 were doubled and the upper 128 were inaccessible. Many registers
had special meanings, including program status, cycle timer and a few
others.
Internally, memory was fetched 512 bits ("Super word" or "sword";
really 544 bits with ECC included) and the vector pipes were 128 bits
wide (2 single-precision results per cycle).
An odd machine in that scalar operations were most decidedly RISC in
attitude. For example, there were only load and store register-
memory operations and one had to use 2 instructions (EX and ELEN) to
enter a full 64-bit immediate constant into a register. No stack or
auto-increment/decremet per se; subroutine linkage was done with a
sort of S/360-style LM-STM combo "swap" instruction that
simultaneously stored and loaded any number of registers. The
machine architecture itself was basically 3-address, so instructions
were either 32 bits or 64 bits in length.
Before an ECO ("Rev. R") was installed on all systems, all registers
could also be addressed as the lower 256 words of user memory address
space. This hugely complicated instruction scheduling and so it was
determined that it wasn't needed.
I know you guys used the RED OS, but we had to use STAR-OS from LLL
as our base in Sunnyvale. It was basically a message-passing OS with
a controller started by the job scheduler, which could have as many
controllees as desired. You could send a message up the chain, one
level, or to the top or broadcast to all controllees. I recall that
the termination message content was the characters "ALL DONE".
Regarding paging, I saw my share of DEADBEEF codes (was the STAR OS
the first to use this failure code?). At some point we went from a
demand-paging algorithm to a working-set one, but the stuff that the
pager had to keep track of made the code a nightmare. Jim Smith
suffered a lot on that thing. It didn't help that we had to scavenge
time on the customer systems at LLL or hop the "noon balloon" out of
San Jose to use the system at ADL.
One thing that I never got to try on the 100 was seeing how long a
maximum-length packed BCD divide would take. Given that the byte
instruction field lengths were 16 bits, it meant either 65K or 131K
digits...
One memory I have is being sent to Arden Hills in January during the
OPEC oil embargo and settling in for the night in the machine room at
ADL because it was warmer than my room at the Ramada.
I"d love to find someone who spent time on the TI ASC to compare
notes...
--Chuck
4 Nov
4 Nov
7:39 a.m.
New subject: CDC STAR was: Happy Birthday VAX 11/780 (influence of)
Chuck Guzis wrote:
On 31 Oct 2010
at 8:21, Jerome H. Fine wrote:
Interesting!! I worked for CDC in Toronto from
around 1972 to 1977 on
the local PL-50 program. IIRC, the PL-50 was a much slower version of
the STAR-100, but with the same instruction set. Initially, the goal
was to write an operating system.
I was part of the Sunnyvale mafia and worked with quite a number of
your Canadian co-workers. Anil and I later partnered up on the
FORTRAN compiler for the ETA-10. You probably remember that the PL-
50/STAR-65 met an unfortunate fate at the hands of the corporate
"leave nothing behind" people. I witnessed firsthand, the
destruction of the two STAR-1B systems a couple of years later. It
wasn't pretty--a dumpster, bolt cutters and large hammers. I saved a
heatsink from the power supply--there wasn't much else left intact.
I begged to be allowed to take the ROS stack from one system, but no
such luck. The stations were removed and sent back to Arden Hills.
I'm going from memory on this one, but there's
some STAR literature
on bitsavers if you want to check my facts.
256 registers of 64 bits; if halfword mode was selected, the lower
128 were doubled and the upper 128 were inaccessible. Many registers
had special meanings, including program status, cycle timer and a few
others.
Internally, memory was fetched 512 bits ("Super word" or "sword";
really 544 bits with ECC included) and the vector pipes were 128 bits
wide (2 single-precision results per cycle).
An odd machine in that scalar operations were most decidedly RISC in
attitude. For example, there were only load and store register-
memory operations and one had to use 2 instructions (EX and ELEN) to
enter a full 64-bit immediate constant into a register. No stack or
auto-increment/decremet per se; subroutine linkage was done with a
sort of S/360-style LM-STM combo "swap" instruction that
simultaneously stored and loaded any number of registers. The
machine architecture itself was basically 3-address, so instructions
were either 32 bits or 64 bits in length.
I am almost certain that the subroutine linkage was quite transparent to
the user, so
a stack of sorts must have been maintained. However, I can't remember
any of the
details, so it's a mute point of how it was done.
I did recall that there were 256 registers with some being 32 bits and
others being 64 bits.
Now that you mention the details, I do remember how useful it was to
have sufficient
temporary registers for almost every situation. With the 32 bit X86
instruction set, there
are too few registers and even the 6 registers (0 to 5) on the PDP-11
are no better. On the
other hand, with L1 cache on the Pentium III (and later models), data
storage is really
not a timing problem for even a few K bytes of data.
Before an ECO ("Rev. R") was installed on all
systems, all registers
could also be addressed as the lower 256 words of user memory address
space. This hugely complicated instruction scheduling and so it was
determined that it wasn't needed.
I never found anyone who made use of the registers for code since there
did not
seem to be many times that operating system code could make use if that
feature.
I know you guys used the RED OS, but we had to use
STAR-OS from LLL
as our base in Sunnyvale. It was basically a message-passing OS with
a controller started by the job scheduler, which could have as many
controllees as desired. You could send a message up the chain, one
level, or to the top or broadcast to all controllees. I recall that
the termination message content was the characters "ALL DONE".
Regarding paging, I saw my share of DEADBEEF codes (was the STAR OS
the first to use this failure code?). At some point we went from a
demand-paging algorithm to a working-set one, but the stuff that the
pager had to keep track of made the code a nightmare. Jim Smith
suffered a lot on that thing. It didn't help that we had to scavenge
time on the customer systems at LLL or hop the "noon balloon" out of
San Jose to use the system at ADL.
Fortunately, at CDC in Toronto, we had our own PL-50 (STAR-65)
hardware. I used
to get the night shift from midnight to 8 AM every Friday morning for
testing on the paging
algorithm. While 8 hours was probably more time than I usually needed,
few people wanted
to start at 6 AM.
I think I remember that RED OS may have been the name, but I am not
sure. Even most
of the code for the paging was MALUS with a few inline instructions when
absolutely
necessary. As I think I mentioned, the demand paging was helped by
keeping a pool
of unaltered pages available so that only the READ of the new page was
required when
the user program had a page fault. Every time the operating system code
was invoked to
handle a page fault and a new user page was needed, after the READ was
initiated and
the system was waiting, the LRU stack of user pages was checked to
determine if there
were any altered pages near the bottom which would likely be discarded.
If so, that
user page was backed up on disk and then kept as being unaltered (unless
the user
referenced it again - in which case the hardware again set the altered
bit) and could
immediately be removed from the current available user pages when it
became the
actual LRU page.
One thing that I never got to try on the 100 was seeing
how long a
maximum-length packed BCD divide would take. Given that the byte
instruction field lengths were 16 bits, it meant either 65K or 131K
digits...
One memory I have is being sent to Arden Hills in January during the
OPEC oil embargo and settling in for the night in the machine room at
ADL because it was warmer than my room at the Ramada.
I"d love to find someone who spent time on the TI ASC to compare
notes...
--Chuck
TI ASC???
Jerome Fine
30 Oct
30 Oct
2:27 p.m.
> I'd say you have virtual memory.
On Sat, 30 Oct 2010, Chuck Guzis wrote:
So, your definition ties virtual memory into . . .
That's not the way I learned it.
That's not virtual memory by any stretch of the definition. . . .
So I think we differ considerably in our definitions.
Thank you, Chuck!
As usual the bulk of the argument was semantics and differing definitions.
Depending on the definitions, even LIM EMS could be considered to be
"memory-mapped" "Virtual" memory.
Even Magnetic Drum memory would meet some definitions.
We all seem to like a good technical argument, but we never seem to be
willing to clarify the terminology until late in the discussion.
--
Grumpy Ol' Fred cisin at xenosoft.com
3:20 p.m.
On 30 Oct 2010 at 14:27, Fred Cisin wrote:
We all seem to like a good technical argument, but we
never seem to be
willing to clarify the terminology until late in the discussion.
It reminds me of last week's discussion of "Random Access Memory" not
applying to magnetic drum.
So, is NCR's CRAM (card random access memory) "Random Access Memory"?
--Chuck
5162
days inactive
5168
days old
9 comments
6 participants
participants (6)
-
bqt＠softjar.se -
cclist＠sydex.com -
cisin＠xenosoft.com -
hilpert＠cs.ubc.ca -
jhfinedp3k＠compsys.to -
mcguire＠neurotica.com