Messages in this thread |  | | Date | Thu, 7 Sep 2000 02:04:30 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: We are as good as our tools |
| |
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/
|  |