Small Address Space
ucbvax!editor-people
One is always dealing with a problem for which a larger address space is
advantageous. Any program on the 20 uses paging, whether it knows it or
not. I don't think that constricts the programmer as RMS implies, nor
is it terribly slow. It turns out that the system demand pager is not
nearly as smart as the editor in determining what to page, as you will
realize after considering what happens on two consecutive searches
through an entire buffer that does not fit in physical memory.
So the question is not whether disk paging should be done, but rather
who should do it. I think RMS will agree that if ITS TECO provided a
virtual buffer space that was larger than the 20's address space and
whose paging was invisible at the level of TECO code, there would be no
serious impact on user-written extensions.
-------
ucbvax!editor-people
Operating systems that do paging have special equipment designed to
make it both invisible and efficient. Hand-simulating paging is a
real pain even though it is no fundamental problem. Most people agree
with this; that is why they want machines with bigger address spaces
rather than rushing to simulate the bigger address space in the user
program.
If you think that hand-simulated paging is as good as having it done
invisibly by the system, you're welcome to write all your programs for
11-90's which support 32 megabytes (but can only access 64k at a time)
and switch your page maps by hand. Remember that each switch will
require a system call.
If you already know that an editor can use a large address space,
that's good. Most people are not aware of this. Many think that a
PDP-11 address space would be perfectly sufficient for the editor
PROGRAM. Perhaps people on EDITOR-PEOPLE are more aware of this than
the programming public.
ucbvax!editor-people
The statement that the system demand pager is not as good as
something in the editor is not necessarily true, but it isn't
worth arguing about. Do people really want to discuss this sort
of thing??
ucbvax!editor-people
You're suggesting that it's the smallness of the physical address space that's
a problem. Only operationally, I reply. The programming problem is the small
virtual address space, for holding program and data both. It's good to avoid
having to interpret every reference, where the memory address is large and
the hardware-provided addresses are themselves small.
This was one of the principal problems with programming Hydra; it's isomorphic
to the 11-90 problem RMS mentions. It's unfortunate for the programmer to have
to worry about interpretation of wide addresses at each step of the program.
Interpreters that provide a wide-addressed virtual machine are cute but slow.
ucbvax!editor-people
I want to draw a distinction between program paging in general
and file mapping within an editor or other specialized system.
I do not propose that paging should be eliminated from the
operating system. However, it is perfectly reasonable for an editor or
(other) data base system to map the file itself if the operating
system does not provide this facility.
In the case of a global operation on the file, the editor usually
knows it will need the file pages in sequential order. In this case,
it can start to fetch the required file buffer pages in advance of
when they are referenced its the search code. If limited virtual
address space and physical memory were not a problem, there would be
no need to do so, but in the real world they usually are a problem.
As for paging the program code itself, again it is easiest and nicest
if the operating system can take care of this for you but not totally
impossible to achieve through overlays in certain special cases.
Before this discussion goes any further on this mailing list, let me
state that I am not interested in a "religious" discussion of which
systems, editors, are best, easiest to program on, etc. Nor am I
claiming that one can achieve the same performance from a micro with a
16 bit address space as one gets from a DEC20, or any other such
nonsense.
My original message was in response to a statement that a
PDP11-class processor is insufficient to support a reasonable text
editor. I take "reasonable" to mean a video editor that operates on
files of arbitrary size with a well designed set of local editing
commands plus global search, replacement, and copying, and which can
search a file about as fast as the fastest disk read operation on a
hard disk.
My claim was simply that a PDP11-class processor can support such an
editor if it is well implemented, not that such an editor can be
implemented on a small machine as easily as it can on larger machines.
-------