[-- Attachment #1: Type: text/plain, Size: 473 bytes --] From what I can gather the only way to reasonably examine the disassembly of a program in the early days of Unix was adb. Is this true? Was there a way to easily produce a full disassembly? I'll confess to being fairly ignorant of adb use since I always had dbx or the equivalent available. The first tool I'm aware of to purposefully/primarily produce a full listing is MIPS dis (ca. 1986?) but there must have been something before that for other systems, no? -Henry [-- Attachment #2: Type: text/html, Size: 547 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1918 bytes --] On Sat, Jun 19, 2021 at 11:05 AM Henry Bent <henry.r.bent@gmail.com> wrote: > From what I can gather the only way to reasonably examine the disassembly > of a program in the early days of Unix was adb. Is this true? > From Research, yes - although sdb and later dbx could do it also I think. > Was there a way to easily produce a full disassembly? > Yes, look at the contents in the early USENIX (Harvard) tape. IIRC: Along with the macro-11 assembler and linker, there was also a disassembler -- I want to say it was done at Cooper Union, but it may have been someone else[The CU folks got the DEC PDP-10 BLISS binary to run on an emulator 'good enough' on their 11/45 to they could 'port' the DEC Fortran compiler to V6. They used/built up PDP-11 tools to support that project]. BTW: there was a version of the DEC DDT that was on those early tapes too that somebody wrote. I started with DDT on V6 because I was coming over from the DEC OS world of PDP-10's and RT-11 and adb did not yet exist. But IIRC it was fragile, had issues when V7 came out, so I just taught myself adb when it appeared. There was an even better set of assembly/disassembly/link tools from 'down-under' on ??maybe? the Delaware tape. Plus, Purdue released a ton of microprocessor tools, which included PDP-11 support. All of them tried to use the symbol table to reconstruct things like jsr's and memory access. Somebody [IIRC it was Phil Karn but I don't remember] tried to do some instruction pattern matching / early AI stuff, to see if they could reconstruct some of the code with some human help. As I recall he could pick up pointers and if given some header files for sizes would try to match code snippets, but I have no idea how he got or what happened too it. > I'll confess to being fairly ignorant of adb use since I always had dbx or > the equivalent available. > ᐧ [-- Attachment #2: Type: text/html, Size: 3513 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2229 bytes --] On Sat, 19 Jun 2021 at 11:54, Clem Cole <clemc@ccc.com> wrote: > On Sat, Jun 19, 2021 at 11:05 AM Henry Bent <henry.r.bent@gmail.com> > wrote: > >> From what I can gather the only way to reasonably examine the disassembly >> of a program in the early days of Unix was adb. Is this true? >> > From Research, yes - although sdb and later dbx could do it also I think. > > >> Was there a way to easily produce a full disassembly? >> > Yes, look at the contents in the early USENIX (Harvard) tape. IIRC: Along > with the macro-11 assembler and linker, there was also a disassembler -- I > want to say it was done at Cooper Union, but it may have been > someone else[The CU folks got the DEC PDP-10 BLISS binary to run on an > emulator 'good enough' on their 11/45 to they could 'port' the DEC Fortran > compiler to V6. They used/built up PDP-11 tools to support that project]. > Wait, so it was easier to write an emulator for a PDP-10 binary than it would have been to port BLISS to the PDP-11? Given the different word sizes I would not have expected that. I'll definitely look at those early USENIX tapes - I have copies of them and I did think of them when I was writing this, but (at least the early ones I looked at) don't appear to have a good index of any sort. Did they have a cover sheet or something equivalent that they came with? I'm having trouble imagining dealing with that much unindexed data on an early system. There was an even better set of assembly/disassembly/link tools from > 'down-under' on ??maybe? the Delaware tape. Plus, Purdue released a ton of > microprocessor tools, which included PDP-11 support. All of them tried to > use the symbol table to reconstruct things like jsr's and memory access. > Somebody [IIRC it was Phil Karn but I don't remember] tried to do some > instruction pattern matching / early AI stuff, to see if they > could reconstruct some of the code with some human help. As I recall he > could pick up pointers and if given some header files for sizes would try > to match code snippets, but I have no idea how he got or what happened too > it. > Fascinating. Thank you as always for the insight. -Henry > ᐧ > [-- Attachment #2: Type: text/html, Size: 3902 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2290 bytes --] On Sat, Jun 19, 2021 at 12:33 PM Henry Bent <henry.r.bent@gmail.com> wrote: > Wait, so it was easier to write an emulator for a PDP-10 binary than it > would have been to port BLISS to the PDP-11? Given the different word > sizes I would not have expected that. > BLISS-11 was (way) too big to run in the 64K address of the PDP-11 (even separated I/D). Originally, it was a PDP-10 cross compiler and later moved to the Vax. It generated much better code than the original Ritchie or later Johnson compilers. The code generator/optimizer was famous (literally the book on code optimization was written about it, called of course: "The Design of an Optimizing Compiler" <https://www.amazon.com/Design-Optimizing-Compiler-William-Allan/dp/0444001581> by Wulf and some of his students [ISBN 0444001581] - *a.k.a.* 'The Green Book' worth reading BTW. Later on, DEC's TLG tried at least twice that I know of to make it self-hosting but gave up. Long story (and definitely a different thread) if DEC has not screwed up the marketing of BLISS, I suspect it might have given C a run for the money. But BLISS *vs*. C is a great example of Cole's law that *Simple Economics always beats Sophisticated Architecture* [and using Christensen's 'disruptive theory -- it gets better and supplants the incombent]. Anyway, the compiler/code generator/linker for DEC Fortran-IV for RT-11, RSX, and DOS-11 was written in BLISS-11. So for CU to retarget it for V6 they needed a PDP-10, which they did not have. So they wrote a simulator. I remember when they gave a talk about it at Usenix, somebody asked them how well Tenex ran on it. > Did they have a cover sheet or something equivalent that they came with? > I'm having trouble imagining dealing with that much unindexed data on an > early system. > Not to my knowledge. Two things that I believe we need to do for the TUHS archives to be even more meaningful is 1.) decode them from tp/ar -- even if you read the tape, they are packed together in v5/v6 ar files which are PDP-11 binary. 2.) Create an index of what is there. I've thought about both things but have way too much on my plate to do it myself. > Fascinating. Thank you as always for the insight. > Most welcome. Clem ᐧ [-- Attachment #2: Type: text/html, Size: 6024 bytes --]
> From: Henry Bent > From what I can gather the only way to reasonably examine the > disassembly of a program in the early days of Unix was adb. Is this > true? Was there a way to easily produce a full disassembly? 'adb' is quite late. We had it on the PWB1 (V6 enhanced, basically) system at MIT, so its roots lie before V7. (Every time I run across people who think V7 is early, I go into 'get off my lawn' mode.) The first thing I know of that could disassemble PDP-11 code on Unix was 'db', which dates back to V1: https://minnie.tuhs.org//cgi-bin/utree.pl?file=V1/man/man1/db.1 It wasn't optimal for doing disassembly, because it was non-trivial to dump an entire object file as assembler source - but it could be done. Later (V5 era) there was something called 'cdb', which was 'db' with extensions to make it useful for debugging code whose source was in C: https://minnie.tuhs.org//cgi-bin/utree.pl?file=V4/man/man1/cdb.1 There were other non-Unix disassembler (such as DDT), also. Noel
[-- Attachment #1: Type: text/plain, Size: 661 bytes --] On Sat, Jun 19, 2021 at 2:25 PM Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote: > 'adb' is quite late. We had it on the PWB1 (V6 enhanced, basically) system > at > MIT, so its roots lie before V7. Yeah, it's in the PWB1 source tree. FWIW: Bourne wrote it ( and it is written in his unique 'BourneGOL' C macro dialect) which (I think) makes it a PITA to modify. Later UCB versions for the Vax removed Steve's macros. So it has some sorts of roots in Research, and most of the world did not get to see it until V7 appeared. > (Every time I run across people who think V7 is early, I go into 'get off > my lawn' mode.) > Amen. ᐧ ᐧ [-- Attachment #2: Type: text/html, Size: 2297 bytes --]
[-- Attachment #1: Type: text/plain, Size: 130 bytes --] I remember compiling and playing Langston's "empire" that I was told came from a decompiled executable. This was in the 4.2 days. [-- Attachment #2: Type: text/html, Size: 169 bytes --]
[-- Attachment #1: Type: text/plain, Size: 791 bytes --] For v8 or thereabouts, I spent some time fixing some fundamental bugs in db and found that it was arcane but remarkably powerful. Since it was lower level, it avoided the endemic debugging problem of misleading you about your program: All it could do was tell you what the machine was doing. (Cdb, sdb, and adb were, at least in my experience, always lying to you.) I may be the only person who appreciated db fully. Once the bugs were gone you really could use it to good effect, as long as you understood the CPU. But it was buggy and arcane, no question about that. -rob On Sun, Jun 20, 2021 at 6:46 AM Richard Salz <rich.salz@gmail.com> wrote: > I remember compiling and playing Langston's "empire" that I was told came > from a decompiled executable. This was in the 4.2 days. > [-- Attachment #2: Type: text/html, Size: 1194 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1017 bytes --] Although upon reflection, I think what I did was fix 'adb' and call it 'db'. Haven't had my coffee yet this morning. -rob On Sun, Jun 20, 2021 at 7:49 AM Rob Pike <robpike@gmail.com> wrote: > For v8 or thereabouts, I spent some time fixing some fundamental bugs in > db and found that it was arcane but remarkably powerful. Since it was lower > level, it avoided the endemic debugging problem of misleading you about > your program: All it could do was tell you what the machine was doing. > (Cdb, sdb, and adb were, at least in my experience, always lying to you.) I > may be the only person who appreciated db fully. Once the bugs were gone > you really could use it to good effect, as long as you understood the CPU. > > But it was buggy and arcane, no question about that. > > -rob > > > > > On Sun, Jun 20, 2021 at 6:46 AM Richard Salz <rich.salz@gmail.com> wrote: > >> I remember compiling and playing Langston's "empire" that I was told came >> from a decompiled executable. This was in the 4.2 days. >> > [-- Attachment #2: Type: text/html, Size: 1739 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1491 bytes --] Ah -- if it was adb you redid, no doubt of its power. I used adb for a long time -- PDP-11/VAX/68K but as you said, you could learn a lot about your system. FWIW: we embedded adb into RTU, calling it kdb. We didn't have no fancy VMs to run the system under, when it halted, it halted. On a personal machine that was not a problem and adb/kdb was very cool. Clem On Sat, Jun 19, 2021 at 5:50 PM Rob Pike <robpike@gmail.com> wrote: > Although upon reflection, I think what I did was fix 'adb' and call it > 'db'. Haven't had my coffee yet this morning. > > -rob > > > On Sun, Jun 20, 2021 at 7:49 AM Rob Pike <robpike@gmail.com> wrote: > >> For v8 or thereabouts, I spent some time fixing some fundamental bugs in >> db and found that it was arcane but remarkably powerful. Since it was lower >> level, it avoided the endemic debugging problem of misleading you about >> your program: All it could do was tell you what the machine was doing. >> (Cdb, sdb, and adb were, at least in my experience, always lying to you.) I >> may be the only person who appreciated db fully. Once the bugs were gone >> you really could use it to good effect, as long as you understood the CPU. >> >> But it was buggy and arcane, no question about that. >> >> -rob >> >> >> >> >> On Sun, Jun 20, 2021 at 6:46 AM Richard Salz <rich.salz@gmail.com> wrote: >> >>> I remember compiling and playing Langston's "empire" that I was told >>> came from a decompiled executable. This was in the 4.2 days. >>> >> [-- Attachment #2: Type: text/html, Size: 2850 bytes --]
Rob: "it was arcane but remarkably powerful" Pretty much sums it up. Wasn't your friend when you were a newbie, was really your friend once you got to know it. On Sat, Jun 19, 2021 at 06:55:07PM -0400, Clem Cole wrote: > Ah -- if it was adb you redid, no doubt of its power. I used adb for a > long time -- PDP-11/VAX/68K but as you said, you could learn a lot about > your system. FWIW: we embedded adb into RTU, calling it kdb. We didn't > have no fancy VMs to run the system under, when it halted, it halted. On > a personal machine that was not a problem and adb/kdb was very cool. > > Clem > > On Sat, Jun 19, 2021 at 5:50 PM Rob Pike <robpike@gmail.com> wrote: > > > Although upon reflection, I think what I did was fix 'adb' and call it > > 'db'. Haven't had my coffee yet this morning. > > > > -rob > > > > > > On Sun, Jun 20, 2021 at 7:49 AM Rob Pike <robpike@gmail.com> wrote: > > > >> For v8 or thereabouts, I spent some time fixing some fundamental bugs in > >> db and found that it was arcane but remarkably powerful. Since it was lower > >> level, it avoided the endemic debugging problem of misleading you about > >> your program: All it could do was tell you what the machine was doing. > >> (Cdb, sdb, and adb were, at least in my experience, always lying to you.) I > >> may be the only person who appreciated db fully. Once the bugs were gone > >> you really could use it to good effect, as long as you understood the CPU. > >> > >> But it was buggy and arcane, no question about that. > >> > >> -rob > >> > >> > >> > >> > >> On Sun, Jun 20, 2021 at 6:46 AM Richard Salz <rich.salz@gmail.com> wrote: > >> > >>> I remember compiling and playing Langston's "empire" that I was told > >>> came from a decompiled executable. This was in the 4.2 days. > >>> > >> -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
Rob Pike: Although upon reflection, I think what I did was fix 'adb' and call it 'db'. Haven't had my coffee yet this morning. ==== I don't think so. I did quite a lot of work on adb during my time at the Labs. I remember clearly that it still used all the Bournegol macros when I started; I doubt Rob would have left that there. (It was Rob who translated the shell back to C, I believe.) I got into adb because it still used ptrace and everyone else seemed scared to touch the code to convert it to use /proc. So I fixed that, and fixed sdb too, and finally removed the ptrace call from the kernel. I remember celebrating by expunging ptrace from the UNIX Room copy of the V8 manual. ptrace happened to occupt two facing pages, which I glued together. I did a lot more hacking on adb after that, ranging from little stuff like making # a synonym for 0x in input (so that adb's output could be picked up from the screen and re-used as input, a principle established firmly and correctly by Rob!) to a major restructuring to isolate machine-dependent pieces like instruction decoding and word formats, so that it was simpler not only to make adb work on a new processor architecture but even to make a sort of cross-adb that could, say, correctly interpret a PDP-11 core image on a VAX. (This actually mattered; by the time I arrived Research had no PDP-11s running general-purpose UNIX, but did have LSI-11s acting as Datakit controllers and a standalone power-backed-up LSI-11 that decoded the time signal from WWVB.) I was never really happy about the restructuring; it did more or less what I wanted but it wasn't really graceful. And cross-adb needed a distinct binary for each target. I had thoughts of trying to make a meta-language to describe the target's data formats (simple except for floating point) and how to print its instructions (messier, but I remember being inspired by the clever table-driven code in an disassembler Ken wrote for, I think it was, the NS32000), so that one could load a table from a file at startup; never had the time or the courage to carry through on it. Norman Wilson Toronto ON
And I thank you for it, Rob. I use it still, almost daily.
Brantley
> On Jun 19, 2021, at 5:50 PM, Rob Pike <robpike@gmail.com> wrote:
>
> Although upon reflection, I think what I did was fix 'adb' and call it 'db'. Haven't had my coffee yet this morning.
>
> -rob
>
>
> On Sun, Jun 20, 2021 at 7:49 AM Rob Pike <robpike@gmail.com> wrote:
> For v8 or thereabouts, I spent some time fixing some fundamental bugs in db and found that it was arcane but remarkably powerful. Since it was lower level, it avoided the endemic debugging problem of misleading you about your program: All it could do was tell you what the machine was doing. (Cdb, sdb, and adb were, at least in my experience, always lying to you.) I may be the only person who appreciated db fully. Once the bugs were gone you really could use it to good effect, as long as you understood the CPU.
>
> But it was buggy and arcane, no question about that.
>
> -rob
>
>
>
>
> On Sun, Jun 20, 2021 at 6:46 AM Richard Salz <rich.salz@gmail.com> wrote:
> I remember compiling and playing Langston's "empire" that I was told came from a decompiled executable. This was in the 4.2 days.
[-- Attachment #1: Type: text/plain, Size: 4012 bytes --] I saw this post and it reminded me of a meeting that Dennis and I had with Bill Wulf. At one point, Dennis decided to write an optimizer but gave up after a week or two because when he had coded the data structures he needed he had filled up the PDP-11 memory! It was a very strong part of the Unix meme that Unix and C would run on small computers since most of the universities couldn't afford bigger ones at the time. When PCC came along and started running on 32-bit machines, I started thinking about algorithms for optimization. A problem that I had no good solution for could be illustrated by a simple piece of code: x = *p; y = *q; q gets changed *q = z; The question is, do I need to reload x now because q might have been changed to point to the same place as p? At around this time, Al Aho was invited to go to CMU and give a talk, and he invited me to come with him. We spent about an hour and a half one-on-one with Bill Wulf -- I seem to remember a lot of mutual respect going on. But when I asked him about my problem, he really didn't have much to say about it. I finally got him to agree that his compiler had a bug. But he said there was a flag they could set on the compiler that would turn of optimization and if your program had mysterious bugs, you should use the flag. I recall that Al, always in search of better algorithms, was a bit disappointed -- I was a bit more pragmatic about it. On the whole, it was a good meeting, and the "Engineering ... Compiler" book was one of my favorites when it came out. Steve --- On 2021-06-19 09:59, Clem Cole wrote: > On Sat, Jun 19, 2021 at 12:33 PM Henry Bent <henry.r.bent@gmail.com> wrote: > >> Wait, so it was easier to write an emulator for a PDP-10 binary than it would have been to port BLISS to the PDP-11? Given the different word sizes I would not have expected that. > > BLISS-11 was (way) too big to run in the 64K address of the PDP-11 (even separated I/D). Originally, it was a PDP-10 cross compiler and later moved to the Vax. It generated much better code than the original Ritchie or later Johnson compilers. The code generator/optimizer was famous (literally the book on code optimization was written about it, called of course: "The Design of an Optimizing Compiler" [1] by Wulf and some of his students [ISBN 0444001581] - _a.k.a._ 'The Green Book' worth reading BTW. > > Later on, DEC's TLG tried at least twice that I know of to make it self-hosting but gave up. Long story (and definitely a different thread) if DEC has not screwed up the marketing of BLISS, I suspect it might have given C a run for the money. But BLISS _vs_. C is a great example of Cole's law that _Simple Economics always beats Sophisticated Architecture_ [and using Christensen's 'disruptive theory -- it gets better and supplants the incombent]. > > Anyway, the compiler/code generator/linker for DEC Fortran-IV for RT-11, RSX, and DOS-11 was written in BLISS-11. So for CU to retarget it for V6 they needed a PDP-10, which they did not have. So they wrote a simulator. I remember when they gave a talk about it at Usenix, somebody asked them how well Tenex ran on it. > >> Did they have a cover sheet or something equivalent that they came with? I'm having trouble imagining dealing with that much unindexed data on an early system. > > Not to my knowledge. Two things that I believe we need to do for the TUHS archives to be even more meaningful is 1.) decode them from tp/ar -- even if you read the tape, they are packed together in v5/v6 ar files which are PDP-11 binary. 2.) Create an index of what is there. > > I've thought about both things but have way too much on my plate to do it myself. > >> Fascinating. Thank you as always for the insight. > > Most welcome. > Clem > ᐧ Links: ------ [1] https://www.amazon.com/Design-Optimizing-Compiler-William-Allan/dp/0444001581 [-- Attachment #2: Type: text/html, Size: 8693 bytes --]
I sent a reply to this message to the TUHS mailing list but gmail may
have rejected it and flagged it as spam.
Please email me privately to let me know if the message made it to the list.
-Paul W..
On 7/1/21, scj@yaccman.com <scj@yaccman.com> wrote:
> I saw this post and it reminded me of a meeting that Dennis and I had
> with Bill Wulf. At one point, Dennis decided to write an optimizer but
> gave up after a week or two because when he had coded the data
> structures he needed he had filled up the PDP-11 memory! It was a very
> strong part of the Unix meme that Unix and C would run on small
> computers since most of the universities couldn't afford bigger ones at
> the time.
>
> When PCC came along and started running on 32-bit machines, I started
> thinking about algorithms for optimization. A problem that I had no
> good solution for could be illustrated by a simple piece of code:
>
> x = *p;
>
> y = *q;
>
> q gets changed
>
> *q = z;
>
> The question is, do I need to reload x now because q might have been
> changed to point to the same place as p? At around this time, Al Aho
> was invited to go to CMU and give a talk, and he invited me to come with
> him. We spent about an hour and a half one-on-one with Bill Wulf -- I
> seem to remember a lot of mutual respect going on. But when I asked him
> about my problem, he really didn't have much to say about it. I finally
> got him to agree that his compiler had a bug. But he said there was a
> flag they could set on the compiler that would turn of optimization and
> if your program had mysterious bugs, you should use the flag.
>
> I recall that Al, always in search of better algorithms, was a bit
> disappointed -- I was a bit more pragmatic about it. On the whole, it
> was a good meeting, and the "Engineering ... Compiler" book was one of
> my favorites when it came out.
>
> Steve
Apparently the email did make it to the TUHS list even though gmail
seemed to have bounced it as spam. Go figure.
Thanks to all who responded.
-Paul W.
On 7/2/21, Paul Winalski <paul.winalski@gmail.com> wrote:
> I sent a reply to this message to the TUHS mailing list but gmail may
> have rejected it and flagged it as spam.
>
> Please email me privately to let me know if the message made it to the
> list.
>
> -Paul W..
[-- Attachment #1: Type: text/plain, Size: 2148 bytes --] On a related (optimization) theme, https://research.swtch.com/hwmm On Fri, Jul 2, 2021 at 12:58 PM Paul Winalski <paul.winalski@gmail.com> wrote: > I sent a reply to this message to the TUHS mailing list but gmail may > have rejected it and flagged it as spam. > > Please email me privately to let me know if the message made it to the > list. > > -Paul W.. > > On 7/1/21, scj@yaccman.com <scj@yaccman.com> wrote: > > I saw this post and it reminded me of a meeting that Dennis and I had > > with Bill Wulf. At one point, Dennis decided to write an optimizer but > > gave up after a week or two because when he had coded the data > > structures he needed he had filled up the PDP-11 memory! It was a very > > strong part of the Unix meme that Unix and C would run on small > > computers since most of the universities couldn't afford bigger ones at > > the time. > > > > When PCC came along and started running on 32-bit machines, I started > > thinking about algorithms for optimization. A problem that I had no > > good solution for could be illustrated by a simple piece of code: > > > > x = *p; > > > > y = *q; > > > > q gets changed > > > > *q = z; > > > > The question is, do I need to reload x now because q might have been > > changed to point to the same place as p? At around this time, Al Aho > > was invited to go to CMU and give a talk, and he invited me to come with > > him. We spent about an hour and a half one-on-one with Bill Wulf -- I > > seem to remember a lot of mutual respect going on. But when I asked him > > about my problem, he really didn't have much to say about it. I finally > > got him to agree that his compiler had a bug. But he said there was a > > flag they could set on the compiler that would turn of optimization and > > if your program had mysterious bugs, you should use the flag. > > > > I recall that Al, always in search of better algorithms, was a bit > > disappointed -- I was a bit more pragmatic about it. On the whole, it > > was a good meeting, and the "Engineering ... Compiler" book was one of > > my favorites when it came out. > > > > Steve > [-- Attachment #2: Type: text/html, Size: 3054 bytes --]