[TUHS] nm on Third Edition .o files?'

[TUHS] nm on Third Edition .o files?'

[Noel Chiappa]

    > More here:
    >   http://minnie.tuhs.org/pipermail/tuhs/2014-October/005218.html

Which sez:

  There is a second document, untitled, no date, which I have not been able to
  locate online at all.
  ..
  From the content, it seems to be from shortly after the previous one, so say,
  circa 1977.

I poked around in a dump of the CSR Unix which I now have available to me, and
found a copy of it. I just checked the Internet (using the canonical search
engine) for various phrases from it, but I still could not turn it up. So,
here it is in machine-readable form:

  http://ana-3.lcs.mit.edu/~jnc/history/unix/CChanges.txt

Hope this is some use to someone... :-)

	Noel

[TUHS] nm on Third Edition .o files?'

[Tony Finch]

Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>
>   http://ana-3.lcs.mit.edu/~jnc/history/unix/CChanges.txt

This is great, thanks! It's interesting how much of C was still quite new
when K&R1 was written.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Rockall, Malin, Hebrides, Bailey, Fair Isle, Faeroes: West or southwest 7 to
severe gale 9. High, occasionally very high except in Fair Isle. Squally
wintry showers, occasionally thundery. Good, occasionally poor.

[TUHS] nm on Third Edition .o files?'

[Ron Natalie]

I was referring to the fact that arrays sometimes are types and sometimes
dissolve into pointers to their first elements.    It's a kludgy concept.
Assignment of array objects or passing/returning them should have been
really implemented at the same time sturct passing/return/assignment was
done.
The fact that a function that appears to pass/take array arguments magically
converts to pointers is kludgy.

-----Original Message-----
From: TUHS [mailto:tuhs-bounces@minnie.tuhs.org] On Behalf Of Noel Chiappa
Sent: Tuesday, December 20, 2016 1:45 PM
To: tuhs at minnie.tuhs.org
Cc: jnc at mercury.lcs.mit.edu
Subject: Re: [TUHS] nm on Third Edition .o files?'

    > From: "Ron Natalie"

    > At some point .. and the ability to assign/pass structures got
    > supported, though I thought that was the compiler that came with V7.

That is my vague recollection too.

    > I'm still annoyed they didn't fix arrays when they fixed structs.

Which aspect? The ability to assign/pass/return arrays, or the funky way
that array naming worked (I'm trying to remember the details, I think it was
something to do with 'arrays' passed as arguments - it was actually a
pointer that was passed, but the declaration didn't have to say 'pointer').

	Noel

[TUHS] nm on Third Edition .o files?'

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2752 bytes --]

touchė

On Tue, Dec 20, 2016 at 3:23 PM, Steve Johnson <scj at yaccman.com> wrote:

> I had a funny and somewhat embarrassing experience around the whole issue
> of structure name spaces.  When types were spreading through C, we had a
> lot of discussion about whether we should require all programs to call
> structures with a structure pointer (which would allow a separate name
> space for structure members of each structure).   We all thought it was a
> good idea, but the problem was there was a lot of code out there that
> didn't conform, including a lot of OS code.  As we started to port Unix to
> the Interdata (a 32-bit machine), the situation became critical.  So I took
> a deep breath and implemented the following: the compiler would use the old
> style structure rules until I saw a "new style" structure reference in the
> code.  At that point I would start to enforce the new rules, which involved
> translating the symbol table, and starting to complain if the types didn't
> match.   This was a very ugly hack, and I had inserted many firewalls and
> assertions to check that the data structures were correct after this
> translation.
>
> Now, a word about error messages.  The PDP-11 didn't have much memory.
> But at the same time it didn't have much of a debugger in those days.  So
> the main aim was to identify what went wrong in a small number of
> characters so you could put in print statements and run it again.  This
> meant that the message produced had to be short but also unique.  I was
> producing error checks at a great rate in this code and running out of
> synonyms for "corrupted" in my messages.
>
> I "published" the code, and everything seemed to be working for a couple
> of days.  Then Ken, who was working on the Interdata file system, tried to
> compile a structure declaration that contained a sizeof of a structure that
> was recursively declared inside of the sizeof, and my code gave up the
> ghost.  Ken came into my office with a strange look on his face and asked
> "What is a gummy structure?"
>
>
> ----- Original Message -----
> From:
> "Clem Cole" <clemc at ccc.com>
>
> To:
> "Larry McVoy" <lm at mcvoy.com>
> Cc:
> "TUHS main list" <tuhs at minnie.tuhs.org>, "Noel Chiappa" <
> jnc at mercury.lcs.mit.edu>
> Sent:
> Tue, 20 Dec 2016 11:21:41 -0500
> Subject:
> Re: [TUHS] nm on Third Edition .o files?'
>
>
>
> On Tue, Dec 20, 2016 at 11:09 AM, Larry McVoy <lm at mcvoy.com> wrote:
>
>> I get that it doesn't scale but man, so nice when reading
>> code to know that s.st_size is a stat structure.
>>
>
> ​Amen!!!​
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161220/b941b212/attachment.html>

[TUHS] nm on Third Edition .o files?'

[Steve Johnson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2624 bytes --]

I had a funny and somewhat embarrassing experience around the whole
issue of structure name spaces.  When types were spreading through C,
we had a lot of discussion about whether we should require all
programs to call structures with a structure pointer (which would
allow a separate name space for structure members of each
structure).   We all thought it was a good idea, but the problem was
there was a lot of code out there that didn't conform, including a lot
of OS code.  As we started to port Unix to the Interdata (a 32-bit
machine), the situation became critical.  So I took a deep breath and
implemented the following: the compiler would use the old style
structure rules until I saw a "new style" structure reference in the
code.  At that point I would start to enforce the new rules, which
involved translating the symbol table, and starting to complain if the
types didn't match.   This was a very ugly hack, and I had inserted
many firewalls and assertions to check that the data structures were
correct after this translation.

Now, a word about error messages.  The PDP-11 didn't have much
memory.  But at the same time it didn't have much of a debugger in
those days.  So the main aim was to identify what went wrong in a
small number of characters so you could put in print statements and
run it again.  This meant that the message produced had to be short
but also unique.  I was producing error checks at a great rate in
this code and running out of synonyms for "corrupted" in my messages.

I "published" the code, and everything seemed to be working for a
couple of days.  Then Ken, who was working on the Interdata file
system, tried to compile a structure declaration that contained a
sizeof of a structure that was recursively declared inside of the
sizeof, and my code gave up the ghost.  Ken came into my office with
a strange look on his face and asked "What is a gummy structure?"

----- Original Message -----
From:
 "Clem Cole" <clemc at ccc.com>

To:
"Larry McVoy" <lm at mcvoy.com>
Cc:
"TUHS main list" <tuhs at minnie.tuhs.org>, "Noel Chiappa"
<jnc at mercury.lcs.mit.edu>
Sent:
Tue, 20 Dec 2016 11:21:41 -0500
Subject:
Re: [TUHS] nm on Third Edition .o files?'

On Tue, Dec 20, 2016 at 11:09 AM, Larry McVoy <lm at mcvoy.com [1]>
 wrote:

I get that it doesn't scale but man, so nice when reading
 code to know that s.st_size is a stat structure.

​Amen!!!​

 

Links:
------
[1] mailto:lm at mcvoy.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161220/95e6a0a7/attachment.html>

[TUHS] nm on Third Edition .o files?'

[Noel Chiappa]

    > From: "Ron Natalie"

    > At some point .. and the ability to assign/pass structures got
    > supported, though I thought that was the compiler that came with V7.

That is my vague recollection too.

    > I'm still annoyed they didn't fix arrays when they fixed structs.

Which aspect? The ability to assign/pass/return arrays, or the funky way that
array naming worked (I'm trying to remember the details, I think it was
something to do with 'arrays' passed as arguments - it was actually a pointer
that was passed, but the declaration didn't have to say 'pointer').

	Noel

[TUHS] nm on Third Edition .o files?'

[Larry McVoy]

On Tue, Dec 20, 2016 at 11:23:34AM -0500, Ron Natalie wrote:
> And nothing precludes you from tagging the structure elements.
> We continued to do that long after the compiler was ???fixed.???

Oh, agreed.  The aware people do that.  I just wish it was the default
that it enforced one namespace.  For all i know gcc has this and I 
haven't noticed.

[TUHS] nm on Third Edition .o files?'

[Ron Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 712 bytes --]

And nothing precludes you from tagging the structure elements.    We continued to do that long after the compiler was “fixed.”



 

From: Clem Cole [mailto:clemc@ccc.com] 
Sent: Tuesday, December 20, 2016 11:22 AM
To: Larry McVoy
Cc: Ron Natalie; Noel Chiappa; TUHS main list
Subject: Re: [TUHS] nm on Third Edition .o files?'

 

 

On Tue, Dec 20, 2016 at 11:09 AM, Larry McVoy <lm at mcvoy.com> wrote:

I get that it doesn't scale but man, so nice when reading
code to know that s.st_size is a stat structure.

 

​Amen!!!​

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161220/21db0f19/attachment-0001.html>

[TUHS] nm on Third Edition .o files?'

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 367 bytes --]

On Tue, Dec 20, 2016 at 11:09 AM, Larry McVoy <lm at mcvoy.com> wrote:

> I get that it doesn't scale but man, so nice when reading
> code to know that s.st_size is a stat structure.
>

​Amen!!!​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161220/8fd7815f/attachment.html>

[TUHS] nm on Third Edition .o files?'

[Larry McVoy]

On Tue, Dec 20, 2016 at 11:04:13AM -0500, Ron Natalie wrote:
> At some point, the structure elements being made unique to the structure they were defined in

I, for one, would have been really OK if that had been optional.
If it is what I am thinking about, that all struct elements were in the
same namespace, forcing names like "st_size" instead of just "size",
I love that.  I get that it doesn't scale but man, so nice when reading
code to know that s.st_size is a stat structure.

[TUHS] nm on Third Edition .o files?'

[Ron Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 848 bytes --]

If I recall, we got the typesetter (troff) tape in between V6 and the later (I think we got PWB next then V7).    It had a compiler on it.    I presume that it was needed to compile troff, but most of us installed it as a more up to date C compiler.    If I recall properly (and boy my mind is hazy on this), is that it supported the “new” += syntax while warning that =+ was deprecated.   

 

At some point, the structure elements being made unique to the structure they were defined in, and the ability to assign/pass structures got supported, though I thought that was the compiler that came with V7.

I’m still annoyed they didn’t fix arrays when they fixed structs.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161220/96a20a72/attachment.html>

[TUHS] nm on Third Edition .o files?'

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1884 bytes --]

On Tue, Dec 20, 2016 at 8:05 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

> I think a lot of it was
> ​ ​
> related to work being done on typetting stuff, hence the moniker
> 'phototypsetter compiler' which was applied to that 'improved' C.
>

​Need to ask someone like Doug or Steve - but I thought/IIRC the moniker
was because it was the compiler an end user got when you get the typesetter
code.   ​That said, you have to be right in that it was the typesetter work
that seems to be the forcing function.  As for dating it, it has to have
predated the "white book" because we had the typesetter compiler at CMU
before Ted Kowalski showed up for his OYOC year which I'm pretty sure was
'76.

He had brought UNIX/TS with him and a xerographic copy of the white book
proofs.  We had been running 5th and then 6th edition in '75 - when I
started hacking.   Ted updated us to his system and that spread everywhere
but the two CS IUS and SUS (image and speech understanding systems).

I believe that I can date this because IUS and SUS had a special CMU 11/40e
microcode (csav and cret instructions) and hacked typesetter C compiler,
which was different from what Ted was using (which was even later).   So
these systems could not use Ted's new kernel until someone in CS brought
the two compilers in sync (Dan Klein maybe??) - I remember is was a pain in
the tuckus because you could not take a binary from the CS systems and run
them on the EE Dept systems.  But the CS system had more disk than we did,
so they had all of the sources from outside places like MIT, UCB, et al on
line.   We I was grabbing tools from those systems to update the EE systems
and pushing what we wrote back to them.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161220/383818e0/attachment.html>

[TUHS] nm on Third Edition .o files?'

[Noel Chiappa]

PS:

    > I recall 2-3 notes to users about the evolution of C post 'vanilla' V6
    > ...
    > One of the notes is fairly common, but another I have only in hardcopy
    > (although I scanned it at one point).

More here:

  http://minnie.tuhs.org/pipermail/tuhs/2014-October/005218.html

If anyone knows of any other documentation of C evolution, I'd be interested
in hearing about it for the Computer History wiki page.

	Noel

[TUHS] nm on Third Edition .o files?'

[Noel Chiappa]

    > From: Tony Finch

    > when did C get its cast operator?

Well after that piece of code was written! :-)

I don't recall exactly off the top of my head, but I recall 2-3 notes to
users about the evolution of C post 'vanilla' V6; I think a lot of it was
related to work being done on typetting stuff, hence the moniker
'phototypsetter compiler' which was applied to that 'improved' C. 

One of the notes is fairly common, but another I have only in hardcopy
(although I scanned it at one point).

I'll try and turn all of them, along with some notes I made about the
differences between 'vanilla' V6 C and 'phototypsetter C' (which a lot of the
later V6 users started with - I certainly did), into an article on the
Computer History wiki on the early evolution of C.

	Noel

[TUHS] nm on Third Edition .o files?

[Tony Finch]

Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:

> I wonder why it was written as "0177776->integ", rather than "*017776"?
> Probably the former allowed the C compiler to work out what size the
> operand was.

I guess the alternatives would be casting (when did C get its cast
operator?) or assigning the number to a pointer variable.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Viking, North Utsire: Southerly veering southwesterly later, 7 to severe gale
9, occasionally storm 10 in north. Very rough or high. Occasional rain. Good,
occasionally poor.

[TUHS] nm on Third Edition .o files?

[Noel Chiappa]

    > From: "Steve Johnson"

    > The number on the left is a PDP-11 address, probably for some kind of
    > control register.

It's the Processor Status Word, which contained the CPU's hardware priority
level, condition codes, etc.

    > That's a construction that's left over from B.

I wonder why it was written as "0177776->integ", rather than "*017776"?
Probably the former allowed the C compiler to work out what size the operand
was. (BTW, 'integ' was declared in a structure declaration as follows:

    struct {
	int	integ;
    };

(Did the code looked at actually say "0177776->int"? The compiler might have
barfed on a reserved keyword being used like that.)

       Noel

[TUHS] nm on Third Edition .o files?

[Michael Kjörling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 683 bytes --]

On 19 Dec 2016 12:33 -0800, from scj at yaccman.com (Steve Johnson):
>> e.g. "0177776->int =| 300"
> 
> The number on the
> left is a PDP-11 address, probably for some kind of control register.

That was my guess, too. I also want to point out that 0177776 ==
0xfffe. IMO this being near an obvious binary boundary would further
support the theory that it's a control register of some kind.

Interesting bit of C history, Steve; thank you for that tidbit.

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

[TUHS] nm on Third Edition .o files?

[Diomidis Spinellis]

Thank you so much for the explanation.  I was aware that in old C 
structures a->b references were interpreted as *(a + b), but didn't know 
that early C was so close to B that it could run most B programs by just 
adding some declarations.  It seems a logical evolutionary and 
bootstrapping step.

What I'm trying to do is study the dependencies between the kernel's 
files.  Maybe a good approximation would be to consider all functions as 
global and ignore variables.

On 19/12/2016 22:33, Steve Johnson wrote:
> That's a construction that's left over from B.  The number on the left
> is a PDP-11 address, probably for some kind of control register.
>
> In B, all data was stored in the same sized bucket.  For arrays, the
> bucket contained the address of the beginning of the storage allocated
> for the array.  For data, the bucket contained the data.  On a
> byte-addressed machine, Dennis had to do some real magic to load and
> execute these programs (e.g., shift addresses right by a bit).  And, of
> course, because there were no types, there was no type checking, and
> thus no way to disambiguate structure members, so all names of structure
> members had to be unique.  If one structure had a member "next", no
> other structure could have a member "next".   (actually, it could if
> they were at the same offset in the two structures, but that was pretty
> dangerous...).  And early C (originally called nb, "new B") had to be
> able to run most B programs by just adding some declarations...
>
> I can't help you with nm, but it might not tell you much if you had it...
>
> Steve
>
>
>
>     ----- Original Message -----
>     From:
>     "Diomidis Spinellis" <dds at aueb.gr>
>
>     To:
>     "TUHS main list" <tuhs at minnie.tuhs.org>
>     Cc:
>
>     Sent:
>     Mon, 19 Dec 2016 21:47:28 +0200
>     Subject:
>     [TUHS] nm on Third Edition .o files?
>
>     . . .
>
>     However, I stumbled on the use of structure fields on things that
>     aren't
>     structures, e.g. "0177776->int =| 300"
>

[TUHS] nm on Third Edition .o files?

[Steve Johnson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1551 bytes --]

That's a construction that's left over from B.  The number on the
left is a PDP-11 address, probably for some kind of control register.

In B, all data was stored in the same sized bucket.  For arrays, the
bucket contained the address of the beginning of the storage allocated
for the array.  For data, the bucket contained the data.  On a
byte-addressed machine, Dennis had to do some real magic to load and
execute these programs (e.g., shift addresses right by a bit).  And,
of course, because there were no types, there was no type checking,
and thus no way to disambiguate structure members, so all names of
structure members had to be unique.  If one structure had a member
"next", no other structure could have a member "next".   (actually,
it could if they were at the same offset in the two structures, but
that was pretty dangerous...).  And early C (originally called nb,
"new B") had to be able to run most B programs by just adding some
declarations...

I can't help you with nm, but it might not tell you much if you had
it...

Steve

----- Original Message -----
From: "Diomidis Spinellis" <dds@aueb.gr>
To:"TUHS main list" <tuhs at minnie.tuhs.org>
Cc:
Sent:Mon, 19 Dec 2016 21:47:28 +0200
Subject:[TUHS] nm on Third Edition .o files?

. . .

 However, I stumbled on the use of structure fields on things that
aren't 
 structures, e.g. "0177776->int =| 300"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161219/aac0384e/attachment.html>

[TUHS] nm on Third Edition .o files?

[Diomidis Spinellis]

Has anyone got a setup where they can run something like nm(1) on the 
compiled Third Edition Unix C files and send me the output? 
(Alternatively, just send me the .o files, and I'll whip up something to 
read their symbols.)  I tried to compile the source code on a modern 
system by hacking old C to something closer to what GCC will accept, 
with commands such as the following.

cc -E dp.c |
sed 's/=\([&|+-]\)/\1=/g;s/struct[ \t]*(/struct {/' |
gcc -w -x c -

However, I stumbled on the use of structure fields on things that aren't 
structures, e.g. "0177776->int =| 300"