19 Dec
2016
19 Dec
'16
7:47 p.m.
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"
19 Dec
19 Dec
8:33 p.m.
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(a)aueb.gr>
To:"TUHS main list" <tuhs(a)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"
8:49 p.m.
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(a)aueb.gr>
To:
"TUHS main list" <tuhs(a)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"
9:03 p.m.
On 19 Dec 2016 12:33 -0800, from scj(a)yaccman.com (Steve Johnson):
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(a)kjorling.se
“People who think they know everything really annoy
those of us who know we don’t.” (Bjarne Stroustrup)
e.g.
"0177776->int =| 300"
The number on the
left is a PDP-11 address, probably for some kind of control register.
2692
days inactive
2692
days old
3 comments
3 participants
participants (3)
-
Diomidis Spinellis -
Michael Kjörling -
Steve Johnson