Noel Chiappa:
> I tended to be more annoyed by _extra_ characters; e.g. the fact that
> 'change directory' was (in standard V6) "chdir" (as opposed to just
> plain "cd") I found far more irritating! Why make that one _five_
> characters, when most common commands are two?! (cc, ld, mv, rm, cp,
> etc, etc, etc...)
In the earliest systems, e.g. that on the PDP-7, the change-directory
command was just `ch'.
Two vague memories about the change:
-- Dennis, in one of his retrospective papers (possibly that
in the 1984 all-UNIX BLTJ issue, but I don't have it handy at
the moment) remarked about ch becoming chdir but couldn't
remember why that happened.
-- Someone else, possibly Tom Duff, once suggested to me that
in the earliest systems, the working directory was the only
thing that could be changed: no chown, no chmod. Hence just
ch for chdir. I don't know offhand whether that's true, but
it makes a good story.
Personally I'd rather have to type chdir and leav off th
trailing e on many other words than creat if it let me off
dealing with pieces of key system infrastructure that insist
on printing colour-change ANSI escape sequences (with, so far
as I can tell, no way to disable them) and give important files
names beginning with - so that grep pattern * produces an error.
But that happens in Linux, not UNIX.
Norman Wilson
Toronto ON
Thanks for clearing that the whole members out of nowhere thing.
I had thought (ha ha) that since I don't have a working fork, I could just
rebuild CC as a native
executable, and then just call apout for each stage, but I never realized
how interdependent
they all are, at least C0 to C1.
It's crazy to think of how much this stuff cost once upon a time.
And now we live in the era of javascript pdp-11's
http://pdp11.aiju.de/
-----Original Message-----
From: Brantley Coile
To: Jason Stevens
Cc: tuhs(a)minnie.tuhs.org
Sent: 10/27/14 9:03 PM
Subject: Re: [TUHS] speaking of early C compilers
Early C allowed you to use the '->' operator with any scaler. See early
C reference manuals. This is the reason there is one operator to access
a member of a structure using a pointer and another, '.', to access a
member in a static structure. The B language had no types, everything
was a word, and dmr evolved C from B. At first it made sense to use the
'->' operator to mean add a constant to whatever is on the left and use
as an l-value.
You will also find that member names share a single name space. The
simple symbol table had an bit in each entry to delineate members from
normal variables. You could only use the same member name in two
different structs if the members had the same offsets. In other words,
it was legal to add a member name to the symbol table that was already
there if the value of the symbol was the same as the existing entry.
Dennis' compilers kept some backward compatibility even after the
language evolved away from them.
This really shows the value of evolving software instead of thinking one
has all the answers going into development. If one follows the
development of C one sees the insights learned as they went. The study
of these early Unix systems have a great deal to teach that will be
valuable in the post Moore's law age. Much of the worlds software will
need to a re-evolution.
By the way, did you notice the compiler overwrites itself? We used to
have to work in tiny spaces. Four megabytes was four million dollars.
Sent from my iPad
> On Oct 27, 2014, at 6:42 AM, Jason Stevens
<jsteve(a)superglobalmegacorp.com> wrote:
>
> has anyone ever tried to compile any of the old C compilers with a
'modern'
> C compiler?
>
> I tried a few from the 80's (Microsoft/Borland) and there is a bunch
of
> weird stuff where integers suddenly become structs, structures
reference
> fields that aren't in that struct,
>
> c01.c
> register int t1;
> ....
> t1->type = UNSIGN;
>
>
> And my favorite which is closing a bunch of file handles for the heck
of it,
> and redirecting stdin/out/err from within the program instead of just
> opening the file and using fread/fwrite..
>
> c00.c
> if (freopen(argv[2], "w", stdout)==NULL ||
> (sbufp=fopen(argv[3],"w"))==NULL)
>
>
> How did any of this compile? How did this stuff run without
clobbering
> each-other?
>
> I don't know why but I started to look at this stuff with some half
hearted
> attempt at getting Apout running on Windows. Naturally there is no
fork, so
> when a child process dies, the whole thing crashes out. I guess I
could
> simulate a fork with threads and containing all the cpu variables to a
> structure for each thread, but that sounds like a lot of work for a
limited
> audience.
>
> But there really is some weird stuff in v7's c compiler.
> _______________________________________________
> TUHS mailing list
> TUHS(a)minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
> From: random832(a)fastmail.us
> Did casting not exist back then?
No, not in the early V6 compiler. It was only added as of the Typesetter
compiler. (I think if you look in those 'Recent C Changes' things I sent in
recently {Oct 17}, you'll find mention of it.)
Noel
Have you looked at http://real-votrax.no-ip.org/
they have a votrax hooked up, and yes it'll use your phonemes that speak
generates.
It just likes things to be upper case though.
So..
hello
!p
,h,e0,l,o0,o1,-1
works more like
H E0 L O0 O1 PA1
I wonder if anyone's generated wav's for each of the phonemes, then you
could hook up a line printer or something that'll read it as a pipe and just
play the wav's as needed..
It is rough 1970's speech synthesis, but I had one of those Intellivoice
things as a kid, so I kinda like it.
-----Original Message-----
From: Mark Longridge
To: tuhs
Sent: 10/13/14 8:57 AM
Subject: [TUHS] Getting Unix v5 to talk
Thanks to the efforts of Jonathan Gevaryahu I have managed
to get the Unix v5 speak utility to compile and execute.
All this was done using the simh emulator emulating a
PDP-11/70.
Jonathan managed extract enough of speak.c to reconstruct it
to the point it could be compiled with v5 cc. I believe it
was necessary to look at speak.o to accomplish this.
Jonathan also states that there are more interesting things
that could possibly be recovered from v6doc.tar.gz
One can look at speak.c source here:
http://www.maxhost.org/other/speak.c
Now had we have speak compiled we can go a bit further:
cat speak.v - | speak -v null
generates speak.m from ascii file speak.v
speak speak.m
computer
!p (prints out phonetics for working word)
which outputs:
,k,a0,m,p,E2,U1,t,er,-1
ctrl-d exits
Looking at speak.c we can see that it opens /dev/vs.
Fortunately we have the file /usr/sys/dmr/vs.c to look at
so this could be compiled into the kernel although I haven't
done this as yet.
speak.c looks like Unix v5 era code. My understanding is that
Unix v5 appeared in June 1974 and the comments say 'Copyright 1974'
so it seems plausible.
I'm intrigued by the possibility of getting Unix v5 to talk.
Mark
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
> From: "Engel, Michael" <M.Engel(a)leedsbeckett.ac.uk>
> The machine has a Multibus FD controller with its own 8085 CPU and a
> uPD765, connected to a Toshiba 5.25" DD floppy drive (720 kB, 80
> tracks, 9 sectors of 512 bytes), the model identifier is DDF5-30C-34I
> ... I couldn't find any information on that drive online, so I hesitate
> to simply connect a more modern drive due to possible pinout differences.
> ...
> I also found out a bit more on the SMD disk controller. It seems to be
> an OEM variant of the Micro Computer Technology MCT-4300 controller.
> The only place I could find this mentioned was in a catalog of Multibus
> boards on archive.org.
> ...
> So, if you happen to have any information on the Codata floppy
> controller, the Toshiba floppy or the MCT-4300 SMD disk controller, I
> would be happy to hear from you...
I don't, but can I suggest the Classic Computers mailing list:
http://www.classiccmp.org/mailman/listinfo/cctalk
They seem to have an extremely deep well of knowledge, and perhaps someone
there can help? (I'd rate the odds very high on the floppy drive.)
Noel
Hi,
it's time for an update on our progress with the Codata machine.
The serial interface problem was not caused by a defective transceiver
chip (which I found out after buying a couple…), but by an extreme
amount of noise on the (quite long and old) serial cable we used to
connect the machine to the PC acting as a terminal. Using a USB
to serial adapter and a short 9-to-25-pin adapter cable solved this
problem. Well, try the obvious things first (using a scope helped).
The second CPU board also works, so we could build a complete
second machine with our spare boards if we have another multibus
backplane...
We could get the machine up and booting from the first 8" hard disk
last Friday. Luckily, an old version of Kermit was installed and we
were able to transmit a large part of the root file system from single
user more - especially the Unix kernels, driver sources, the build
directories for the kernel, include files and the build directory for
the standalone boot floppies. All with a speed of 500 bytes/s (9600
bps serial line minus kermit overhead). cksum was used to confirm
that the files were transferred correctly (this was the only checksumming
tool that was available on the Codata, I didn't want to mount the fs
read-write and compile software before completing the backup).
I had to shut the machine down on Friday evening (security policy
that kicks you out of the building here), since I didn't want to leave
it running unattended over the weekend. Unfortunately, the disk
seems to have developed a bad sector in the autoconfiguration
region (the system seems to be quite modern in this respect).
The kernel can be booted successfully, but it refuses to mount the
root fs, complaining about a timeout. There seems to be a complete
root file system on the second disk (the firmware is able to read files
from the disk, but it doesn't offer a feature to list directories…), but the
kernel on the second disk also is hardwired to mount its root fs from the
first disk. Trying to connect disk 2 as disk 1 resulted in a non-booting
system...
The good news is that both root file systems seem to be reasonably
intact so far, I can read text files from the boot monitor. So our next
step to backup the rest of the system is to build an emergency boot
floppy. At the moment, however, the Codata refuses to talk to its
floppy drive. The machine has a Multibus FD controller with its own
8085 CPU and a uPD765, connected to a Toshiba 5.25" DD floppy
drive (720 kB, 80 tracks, 9 sectors of 512 bytes), the model identifier
is DDF5-30C-34I (printed on the motor assembly). I couldn't find
any information on that drive online, so I hesitate to simply
connect a more modern drive due to possible pinout differences.
I also found out a bit more on the SMD disk controller. It seems to
be an OEM variant of the Micro Computer Technology MCT-4300
controller. The only place I could find this mentioned was in a
catalog of Multibus boards on archive.org. It has its own driver
(cd.c), there is a separate one for the Interphase 2180 and an
additional one for the Codata MFM controller.
So, if you happen to have any information on the Codata floppy
controller, the Toshiba floppy or the MCT-4300 SMD disk controller,
I would be happy to hear from you...
-- Michael
> From: Greg 'groggy' Lehey <grog(a)lemis.com>
> This is really an identifier issues
Probably actually a function of the relocatable object format / linker on the
machines in question, which in most (all?) cases predated C itself.
> it's documented in K&R 1st edition, page 179:
Oooh, good piece of detective work!
Noel
Hi folks,
I've been looking at Unix v5 cc limitations.
It seems like early cc could only use variable and function names up
to 8 characters.
This limitation occurs in v5, v6 and v7.
But when using the nm utility to print out the name list I see
function test1234() listed as:
000044T _test123
That seems to suggest that only the first 7 characters are
significant, but when looking at other sources they stated that one
can use up to 8 characters.
I hacked up a short program to test this:
main()
{
test1234();
test1235();
}
test1234()
{
printf ("\nWorking");
}
test1235()
{
printf ("\nAlso working");
}
This generated:
Multiply defined: test5.o;_test123
So it would seem that function names can only be 7 characters in
length. I am not sure if limitations of early cc were documented
anywhere. When I backported unirubik to v5 it compiled the longer
functions without any problem.
Did anyone document these sorts of limitations of early cc? Does
anyone remember when cc started to use function names longer than 7
characters?
Mark
> From: Mark Longridge <cubexyz(a)gmail.com>
> It seems like early cc could only use variable and function names up to
> 8 characters.
> This limitation occurs in v5, v6 and v7.
> ...
> That seems to suggest that only the first 7 characters are significant,
> but when looking at other sources they stated that one can use up to 8
> characters.
The a.out symbol tables use 8-character fields to hold symbol names. However,
C automagically and unavoidably prepends an _ to all externals (I forget
about automatics, registers, etc - too tired to check right now), making the
limit for C names 7 characters.
> I am not sure if limitations of early cc were documented anywhere.
I remember reading the above.
Other limits... well, you need to remember that C was still changing in that
period, so limits were a moving target.
> When I backported unirubik to v5 it compiled the longer functions
> without any problem.
ISTR that C truncated external names longer than 7 characters. Probably the
ones in that program were all unique within 7, so you won.
> Did anyone document these sorts of limitations of early cc?
I seem to recall at least one document from that period (I think pertaining
to the so-called 'Typesetter C') about 'changes to C'.
Also, I have started a note with a list of 'issues with C when you're
backporting V7 and later code to V6', I'll see if I can dig them out tomorrow.
Noel
Afternoon,
# /etc/mkfs /dev/rrp1g 145673
isize = 65488
m/n = 3 500
write error: 2
# file rp0g
rp0g: block special (0/6)
# file rp1g
rp1g: block special (0/14)
# file rp0a
rp0a: block special (0/0)
# file rp1a
rp1a: block special (0/8)
# file rrp0a
rrp0a: character special (4/0)
# file rrp1a
rrp1a: character special (4/8)
# file rrp0g
rrp0g: character special (4/6)
# file rrp1g
rrp1g: character special (4/14)
DESCRIPTION
Files with minor device numbers 0 through 7 refer to various
portions of drive 0; minor devices 8 through 15 refer to
drive 1, etc.
The origin and size of the pseudo-disks on each drive are as
follows:
What am I forgetting? I have an image attached, I have modified hp.c to
have NHP as 2.
Is it conflict between rp.c and hp.c? (I patched hp.c to have NHP 2 after
patching NURP in rp.c to be 2).
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects