On Wed, 6 Sep 2000, Stephen Satchell wrote:
> In other parts of the Open Source community, people point with pride to the
> tools they use to do their work. Let's not forget that Ritchie decided
> that he needed a language to speed his development of a quick-n-dirty
> operating system using an old PDP-7 that had been discarded -- when the
> "logical" way would have been to dig right in -- using assembler, the
> language of the day, to try to get the job done. Interesting that the tool
> came first, in the system that gave birth to the effort which is the
> subject of this mailing list...
Eh?
PDP-7 version: 1969, assembler
Transition to PDP-11: 1971, assembler
v1: October 1971, assembler (B had been there, but almost nothing used it)
v2: 1972, assembler
NB, early C: 1972-1973 (dmr)
v3: same timeframe, ken tried to use C in kernel but gave up on that
v4: 1973, rewrite in C (ken and dmr).
Notice that very large piece of the system as we know it was in place in
v3. Moreover, assembler was the language of the day in many cultures, but
not in the Multics one. BTW, EPL was done by Bell Labs group. So
understanding that high-level languages were nice for the system
programming was there. But implementing PL on -7 was obviously out of
question. And B was not too suitable for the kernel (no structures, for
one thing).
C did not come first. Check the manpages of v1 if you doubt it. And keep
in mind that v1 was two years from the beginning. And C was two years in
the future...
BTW, tools are really nice, but I wouldn't call conventional debuggers
a-la [asg]db good ones. I've been _very_ impressed by Acid - after gdb it
feels like a switch from MCR to sh. Small core providing a language with
enough primitives to build the rest of debugger + library + ability to
write new functions. _That_ would be very useful thing to have - you are
not limited to stepping/poking anymore and can actually write functions
that check state consistency/get stats/whatever and use them. I would
really recommend everyone involved in that thread look through the
papers on this thing (USENIX '94; available online on the
plan9.bell-labs.com/sys/doc/) and look at it in work. Something similar
could be really useful - unlike gbd it allows to look at the large picture
without wearing your fingers to bones. Essentially, Acid libraries can be
used as documentation on the state - very expressive beast.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:28 EST