fostel (04/21/83)
Its funny how hardware technology influences peoples thoughts of what
is "good". Unix was born and nurtured on a limited address space cradle
of 64k bytes. Did that environment produce a criple? No.
Rather it produced the so called "UNIX Style", of a minimal OS kernal,
and collections of small useful programs which the OS could "connect"
at run-time. These ideas are generally accepted as good, independent
of any cpu architecture. Indeed, one need merely look at OS/370 and the
s/370 architecture to see that the ideas are not a direct result of the
address space limits. The s/370 operates most of the time in a world
of 12 bit addressing -- all that will fit into the 12 bit displacement
field. More expansive addressing requires trick use of address constants,
arithmetic, multiple base registers and all manner or other stuff. Did
this result in the "UNIX Style"? Is OS/370 a minimal kernal? Are OS
programs typically small, sleek and robust?
Comments about the strangling confines of the 8086 are a load of ____
disguising the deep down lack of understanding or faith in the UNIX
style. Sure its nice to have a zillion byte address space. Sure that
makes it easier to address a 200K array. (Funny, I've never used one.)
Sure tis easier to have a magabyte process image. I'd rather have a
set of smaller, cleanly interfaced programs which are "linked" at run
time by the OS, then a big lumbering OS/370 "subsystem".
Lets all have a moment of silence for the passing of the thing that
brought UNIX into the world and nurtured its early philosophy. And
give thanks that K.T. and D.R. didn't have a 68000 15 years ago.
----GaryFostel----guy (04/22/83)
Its funny how hardware technology influences peoples thoughts of what
is "good". Unix was born and nurtured on a limited address space cradle
of 64k bytes. Did that environment produce a criple? No.
Nobody said it was a "cripple" (two "p"s, please). There are some applications
that REQUIRE more than 64kB of data/stack and/or 64kB of code. Why did
Zilog have a segmented version of their chip? Why did Motorola and National
Semiconductor come out with a chip with a large address space? Why, for
that matter, did *Intel* provide some (not great, but some) support for 32-bit
pointers on the 8086? Why did DEC come out with the VAX? And so on.
Rather it produced the so called "UNIX Style", of a minimal OS kernal,
and collections of small useful programs which the OS could "connect"
at run-time. These ideas are generally accepted as good, independent
of any cpu architecture.
They are, indeed, good ideas; HOWEVER, NOT every application can be written
that way! Why have some many other operating systems implemented overlaying
and virtual arrays? Why have so many people added overlaying to PDP-11 UNIX?
Indeed, one need merely look at OS/370 and the
s/370 architecture to see that the ideas are not a direct result of the
address space limits. The s/370 operates most of the time in a world
of 12 bit addressing -- all that will fit into the 12 bit displacement
field. More expansive addressing requires trick use of address constants,
arithmetic, multiple base registers and all manner or other stuff. Did
this result in the "UNIX Style"? Is OS/370 a minimal kernal? Are OS
programs typically small, sleek and robust?
Comments about the strangling confines of the 8086 are a load of ____
disguising the deep down lack of understanding or faith in the UNIX
style. Sure its nice to have a zillion byte address space. Sure that
makes it easier to address a 200K array. (Funny, I've never used one.)
Sure tis easier to have a magabyte process image. I'd rather have a
set of smaller, cleanly interfaced programs which are "linked" at run
time by the OS, then a big lumbering OS/370 "subsystem".
Bull____, to put it bluntly. Many, if not most, of us have PERSONAL EXPERIENCE
of programs which suffer greatly in being confined in a small address space.
Take PDP-11 INGRES. (Sorry, no Henny Youngman lines here.) It was composed
of 7 processes which communicated through pipes. It seems that the UNIX style
didn't fit INGRES very well. The VAX-11 INGRES is faster, and much of that
is due to the fact that it is *one* process. The fact that YOU have never
used a 200K array doesn't mean that NOBODY uses them; I wrote some scientific
programs on a PDP-11 on RT-11, and I had to overlay them up a blue streak in
order to get them to fit. The "UNIX style" (if people start thinking that
ALL UNIX programs MUST be written in that style, a lot of the UNIX market
will dry up and blow away) works great IF the program divides neatly along
multiple-process lines. Scientific data analysis frequently, for example,
doesn't. I'm sure the people from Sun can give many more examples of
applications that are a LOT happier if they don't have to contort to fit a
limited address space. I have faith that the UNIX style works with applications
that it works with. I have written my share of clean "UNIX-style" programs,
so I resent the implication that I am a Philistine who can't do so.
Lets all have a moment of silence for the passing of the thing that
brought UNIX into the world and nurtured its early philosophy. And
give thanks that K.T. and D.R. didn't have a 68000 15 years ago.
I hate to disappoint you, but I believe D.R.'s current machine is (oh apostasy)
a VAX-11/780. Should Dennis put on the hairshirt, pick up the sackcloth and
ashes, and do penance for daring to question the wisdom of using machines with
a small address space? If UNIX can't advance with technology, I suspect it
really couldn't be called a good modern operating system. However, the fact
that it has adapted to small single-user machines, workstations like the SUN,
and big VAXes indicates that its strengths lie as much with its adaptability
and portability as with some Procrustean bed of a "style" which it enforces
on applications written for it.
As for the particular application that I have trouble with a 16-bit address
space for, it's a word processor. NOTE that Syntrex's word processor, running
on an 8086, requires overlaying, so there's one limitation on the address
space (physical as well as logical) right there. Furthermore, the spelling
checker code in our word processor is completely integrated with the
editor. Yes, you could hive it off into another process. If we kept the
current user interface - which is VERY nice, since you can define a block and
run the spelling checker on that block while editing - the changes needed to
make it multiple processes would be rather kludgy. We would have to keep a
"speller" process around in the background (the overhead for a fork and exec
would be too much if the user only wanted to check one word), and we would have
to construct a complex protocol to pass information between the speller and
the editor. The alternative is to separate the editor and the speller. This
would be wonderful - penalize the user because of the address space limitations
of the machine! Sorry, a user interface involving an editor and a speller
which were two separate programs would be LOUSY. There is NO argument to the
contrary. (And I'm not the only person to say that; several reports, such as
those in "The Seybold Report on Office Systems", repeatedly complain about
systems where you do have to switch between the editor and the spelling checker.
The company from whom we bought the spelling checker also indicate that one
of the biggest complaints they receive is that it is hard to integrate the
editor and the checker.)
If you don't take careful aim before blasting away, you may end up shooting
yourself in the foot...
Guy Harris
RLG Corporation
{seismo,mcnc,we13}!rlgvax!guymat (04/22/83)
Well, I have to reply to this one. Yes, UN*X was born on a 64k/process machine. (Actually, 128k if you use sep I&D. Actually, it was on a PDP7 of unknown properties ...) And YES, that was a problem. I have seen UN*X run on a PDP11 with only 32 Kword (64 kbyte), ONE rk05, and it did run while supporting 17 users. It ran SLOW. And the compilers are two pass, with multiple images and extra temp files; this loaded down the disks, the buffer cache, and the bus. And vi just barely fits on a PDP11. And ... . Yes, suffering leads to self improvement. But rather than saying ``make all programs and programmers work in 64k so that they will write lean mean clean and to-the-point'', why can't we teach ourselves to ask ourselves ``Is the amount of resource this program uses commensurate with its contribution to the well being of the users, the system, and the world?'' ? This is a much better way to go. Teach effective program design and implementation with Kernighan&Plaugher's ELEMENTS. Teach it by example, by reviews (ugh), by requiring programmers to be well--lettered, or good poker players, or fluent in PDP15 assembler, or whatever, but PLEASE don't go enforcing arbitary absolutes because you like to make people suffer. We are programmers, by the great Massbuss adaptor, not Marines. We don't need boot camp at work. -!hou5e!mat Mark Terribile (Duke of deNet)
CCVAX.gil@nosc-cc.arpa (04/27/83)
From: Jim Gilbreath <CCVAX.gil@nosc-cc.arpa> criple is a cripple, Unix is neither.
greep@su-dsn.arpa (04/29/83)
"The s/370 operates most of the time in a world
of 12 bit addressing -- all that will fit into the 12 bit displacement
field."
This is somewhat misleading. Since every memory reference instruction can
designate a base register plus the 12-bit offset, with some instructions
having provisions for a separate index register as well, and since it is
standard practice to use several base registers pointing to consecutive
memory areas, programs are in practice not limited to a 12-bit address space.
That is, it is not necessary to break up a program larger than 4k bytes into
subroutines in order to make use of multiple base registers; the assembler
knows to use the right one, assuming you tell it that you're setting them up.
Fortunately, nobody designs new machines like this any more.billw@sri-unix.UUCP (07/08/83)
#R:ncsu:-118900:sri-unix:16000010:000:272 sri-unix!billw Apr 27 12:01:00 1983 Hey, we all agree that the 8086 64K segment limitation is not really so bad when you are dealing with Code. Inter-segment calls and jumps and things handle all that relatively nicely. the 8086 and its ilk are just a pain to use if you have LARGE data structures... BillW
speaker.umcp-cs%udel-relay@sri-unix.UUCP (07/11/83)
From: Speaker-To-Animals <speaker.umcp-cs@udel-relay> the 8086 and its ilk are just a pain to use if you have LARGE data structures... Ah...and what if your data structure is a colour graphics board? Now you REALLY have fun. Either you must anticipate where the bounarys will occur or you must test the offset pointer to make sure you havn't run over into the next segment! BLECH! "And you thought Z8000 was grody!" - Speaker