[TUHS] nm on Third Edition .o files?

[Steve Johnson]

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"

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