Re: [TUHS] Disassemblers

Re: [TUHS] Disassemblers

[Norman Wilson]

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

Re: [TUHS] Disassemblers

[Noel Chiappa]

    > 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

Re: [TUHS] Disassemblers

[Clem Cole]

[-- 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 --]

[TUHS] Disassemblers

[Henry Bent]

[-- 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 --]

Re: [TUHS] Disassemblers

[Clem Cole]

[-- 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 --]

Re: [TUHS] Disassemblers

[Henry Bent]

[-- 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 --]

Re: [TUHS] Disassemblers

[Clem Cole]

[-- 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 --]

Re: [TUHS] Disassemblers

[Richard Salz]

[-- 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 --]

Re: [TUHS] Disassemblers

[Rob Pike]

[-- 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 --]

Re: [TUHS] Disassemblers

[Rob Pike]

[-- 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 --]

Re: [TUHS] Disassemblers

[Clem Cole]

[-- 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 --]

Re: [TUHS] Disassemblers

[Larry McVoy]

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 

Re: [TUHS] Disassemblers

[Brantley Coile]

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.

Re: [TUHS] Disassemblers

[scj]

[-- 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 --]

Re: [TUHS] Disassemblers

[Paul Winalski]

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

Re: [TUHS] Disassemblers

[Paul Winalski]

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..

Re: [TUHS] Disassemblers

[John P. Linderman]

[-- 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 --]