> From: Mark Longridge <cubexyz(a)gmail.com>
> In Unix v6 there is a file in the TUHS archives
> V6/usr/source/s4/alloc.s
> ..
> In v5 the command "ar t /lib/libc.a" lists the files in the c library
> and that includes alloc.o
Well, at least you have the binary. Dis-assembly time! :-)
> so there should be a source file somewhere.
Ha-ha-ha-ha-HAH! You _are_ an optimist!
I'm not joking about the dis-assembly. Not to worry, it's not too bad (I had
to do it to retrieve the source for the V6 RL bootstraps - and you've got
symbols too), and you've got the V6 alloc.s to guide you - with luck, it did
not get re-written between V5 and V6, and you may have minimal (no?) changes
to deal with?
I don't know which debugger V5 has (db or cdb); if neither, you can spin up a
V6 and do the disassembly there.
Do "db alloc.o > alloc.s" and then type '0?<RETURN>' followed by a whole
bunch of RETURNs. (You can do plain 'db alloc.o' first, to see about how many
CR's you need.) Next do a "nm alloc.o" to get as many symbols as you can.
At that point, I would extract your prototype alloc.s from the emulated
machine so you can use a real editor to work on it. (You should have a way
to get files in and out of the simulated machine; that was one of the
first things I did with my V6 work:
http://www.chiappa.net/~jnc/tech/V6Unix.html
although if you're using SIMH I don't know if that has a way to import
files - a big advantage to using Ersatz-11, although one I didn't know
about when I picked it.)
You may need to go back and do a "xxx/" {with appropriate value for "xxx"}
plus a few CR's to get static constants, but at that point you should have
all the raw data you need to re-create the V5 alloc.s. Obviously, start
by having your proto-allocV5.s in one window, and compare with the
allocV6.s in another... like I said, you may luck out.
The final step, of course, is 'as alloc.s', and then 'cmp a.out alloc.o'.
Noel
> Interesting that they had both - I don't remember hearing about the 37
> but that doesn't mean much. :-)
The only model 33 on any PDP11 in Bell Labs research was the console.
Otherwise all terminals were ASCII devices. Model 37's predated Unix.
doug
Ok, I was trying to understand exactly what the alloc(III) subroutine
does in unix version 5 and I've discovered that the source code for it
appears to be missing.
In Unix v6 there is a file in the TUHS archives
V6/usr/source/s4/alloc.s so I assume there should be a
V5/usr/source/s4/alloc.s as well but I can't find it anywhere.
In v5 the command "ar t /lib/libc.a" lists the files in the c library
and that includes alloc.o so there should be a source file somewhere.
Mark
Davwe Horsfall:
I was surprised when "chdir" became "cd", but I suppose it fits the
philosophy of 2-letter commands.
======
Don't forget that the original spelling, in the PDP-7 UNIX that
had no published manual, was ch.
The 1/e manual spells it chdir. I remember that in one of
Dennis's retrospective papers, he remarks on the change, and
says he can't remember why.
I once asked in the UNIX room if anyone could recall why ch
changed to chdir. Someone, I forget who, suggested it was
because the working directory was the only thing that could
be changed: no chmod or chown in the PDP-7 days. I don't know
whether that's true.
Norman Wilson
Toronto ON
Lyndon Nerenberg:
Do you still consider '^' the shell's inter-command pipe character?
======
No. By the time I first used UNIX, | was well-established as
the official pipeline character; ^ was just a quirky synonym.
I had the impression somehow that ^ was there just to make
life easier on the Model 33 Teletype, which had no | key.
Digging into old manuals, ^ and | appear simultaneously, in
sh(1) in the Fourth Edition. Pipelines first appeared in
3/e, though with a clumsier syntax (not supported by
any current shell I know): where we would now type
ls | wc
the original syntax was
ls > wc >
The trailing > was required to tell the shell to make a pipeline
of the two commands, rather than to redirect output to a file
named wc. One could of course redirect the final command's
output to a file as well:
ls > wc > filecount
Even clumsier: where we would now type
ls | pr -h 'Look at all these files!'
the 3/e shell expected
ls > "pr -h 'Look at all these files!'" >
because its parser bound > to only the single following word.
The original syntax could be reversed too:
wc < ls <
The manual implies this was required if the pipeline's
ultimate input came from a file. Maybe someone with more
energy than I have right now can dig out the source code
and see.
I was originally going to use an example like
who | grep 'r.*' | wc -l
but the old-style version would be anachronistic. There
was no grep yet in 3/e, and wc took no arguments.
I do still have the habit of quoting ^ in command arguments,
but that's still necessary on a few current systems; e.g.
/bin/sh on Solaris 10. Fortunately, that makes it easier
to remember to quote ! as well, something required by the
clumsy command-history mechanism some people like but I don't.
(I usually turn off history but occasionally it gets turned on
by accident anyway.)
Norman Wilson
Toronto ON
>> From: Mark Longridge <cubexyz(a)gmail.com>
>> I thought you folks might be interested in looking at the changes I had
>> to make. It was a bit harder than the port to v6 but porting to v6
>> first did make things a bit easier.
> To save me from poring over 'diff' output :-), what (at a high level) were
> the changes you had to make to get it to run on v5?
> Noel
Briefly the differences were these:
modern to v7: remove all references to void
no vi on v7, v6, and v5 so using ed instead.
no conditional compilation so no way to make a truly universal version
which works on everything.
v7 to v6: use iolib instead of stdio: fopen -> copen, fclose ->
cclose, fgetc -> cgetc, fputc -> cputc
use int (no long or short in v6)
call to srand uses different argument
copen returns an int instead of a file pointer
no strcat in v6 so the function had to be added
v6 to v5: no iolib: fopen -> creat + open, copen -> open, cgetc ->
read, cputc -> write, cclose -> close
no scanf in v5 so I used the source for gets from v7 instead
getchar() leaves a newline in the buffer so I added an extra call to
getchar() immediately before each call to gets
The size of the unirubik executable was 8K for modern Linux, 10K for
v7, 10K for v6, and 5492 bytes for v5.
Generally I was a lot slower trying to edit files with ed rather than
vi but I'm a lot better with ed now. There wasn't really much unix v5
code to look at and I found the v5 manual a bit spartan.
Mark
Larry McVoy:
Looking at git like that is sort of like looking at the size of
a dynamically linked app. Ya gotta add in libc and all the extensions
people use to make it not suck.
=====
In which case one should also add the size of the kernel, or at
least the code paths exercised by a given program.
Not to mention the layers of window systems, networking, desktops,
message buses, name-space managers, programs to emulate 40-year-old
terminal hardware, flashy icons, and so on.
I say all this to underscore Larry's point, not to dispute it.
Everything has gotten more complicated. Some of the complexity
involves reasonable tradeoffs (the move toward replacing binary
interfaces with readable text where space and time are nowhere
near critical, like the /proc and /sys trees in modern Linux).
Some reflects the more-complex world we live in (networking).
But a lot of it seems, to my mind that felt really at home when
it first settled into UNIX in 1981, just plain tasteless.
There are certainly legitimate differences in aesthetic taste
involved, though. I think taste becomes technically important
when it can be mapped onto real differences in how easily a
program can be understood, whether its innards or its external
interface; how easily the program can adapt to different tasks
or environments; and so on.
Norman Wilson
Toronto ON
Tim Newsham:
I was referring to the bell labs guys who wrote linux and later plan9...
=======
Which Bell Labs guys wrote Linux?
I assume you're not referring to Andy Tanenbaum, erstwhile teacher
of a certain famous Finn ...
Norman Wilson
Toronto ON
PS: it's true that the Plan 9 folks at Bell Labs were early
champions of both Unicode and the UTF-8 encoding. Source:
personal memory.
> Remember that writing programs on terminals was a relative latecomer --
> FORTRAN was designed for punched cards.
Remember that FORTRAN also was a latecomer. It was a shock
to convert from the full character set of the Flexowriters at
Whirlwind to the rebarbative upper-case-only of the 704.
In that vein, there was a period when the Chicago Manual Style
disparaged uppercase text, with an exception being made for
computer programs, which of course should be presented in
upper case.
Doug
