19 Jun
2021
19 Jun
'21
3:04 p.m.
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
19 Jun
19 Jun
3:54 p.m.
On Sat, Jun 19, 2021 at 11:05 AM Henry Bent <henry.r.bent(a)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.
ᐧ
4:33 p.m.
On Sat, 19 Jun 2021 at 11:54, Clem Cole <clemc(a)ccc.com> wrote:
On Sat, Jun 19, 2021 at 11:05 AM Henry Bent
<henry.r.bent(a)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.
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
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].
'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
ᐧ
4:59 p.m.
On Sat, Jun 19, 2021 at 12:33 PM Henry Bent <henry.r.bent(a)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
ᐧ
8:44 p.m.
I remember compiling and playing Langston's "empire" that I was told came
from a decompiled executable. This was in the 4.2 days.
9:49 p.m.
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(a)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.
9:50 p.m.
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(a)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(a)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.
10:55 p.m.
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(a)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(a)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(a)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.
>>
>
11:14 p.m.
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(a)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(a)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(a)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
20 Jun
20 Jun
1:41 a.m.
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(a)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(a)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(a)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.
2 Jul
2 Jul
1:36 a.m.
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(a)gmail.com> wrote:
Links:
------
[1]
https://www.amazon.com/Design-Optimizing-Compiler-William-Allan/dp/04440015…
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
ᐧ 
4:56 p.m.
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(a)yaccman.com <scj(a)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
5:45 p.m.
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(a)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..
6:07 p.m.
On a related (optimization) theme,
https://research.swtch.com/hwmm
On Fri, Jul 2, 2021 at 12:58 PM Paul Winalski <paul.winalski(a)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(a)yaccman.com <scj(a)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
1028
days inactive
1041
days old
13 comments
9 participants
participants (9)
-
Brantley Coile -
Clem Cole -
Henry Bent -
John P. Linderman -
Larry McVoy -
Paul Winalski -
Richard Salz -
Rob Pike -
scj＠yaccman.com