I've been looking into the history of yacc (yet another compiler compiler).
The earliest reference I can find is the man page for yacc from v3
which indicates that yacc was written in B language. The files actn.b
and /crp/scj/bigyacc are mentioned. No luck so far in locating those
files.
There is a man page for v4 which is very brief.
There is a yacc executable for v5 but so far I haven't found any v5
era code that works with it. My attempts to compile bc.y from v6 using
yacc from v5 were not successful.
Also the source code for yacc in v5 is missing.
On a happier note I was able to use yacc and cc to regenerate the bc
calculator in v6. It needed a fair amount of swap space to compile
otherwise an "Intermediate file error" will occur. It seemed to
require at least 300 blocks of hard drive space.
It's a bit mysterious what the Unix v5 yacc was used on. It predated
bc and expr. There's no v5 era *.y files available to look at.
Mark
I've been comparing Unix v5 libc to modern linux and various other
Unix versions and I found something odd.
I made a list of functions which occur in Unix v5 libc.a and modern
linux glibc.a and while there is no problem using the ecvt function in
modern linux it doesn't seem to appear:
ar t /usr/lib/libc.a | grep ecvt
...doesn't find ecvt.
But if you do:
grep ecvt /usr/lib/libc.a
then
Binary file /usr/lib/libc.a matches
So it seems it is in there somewhere. While searching for ecvt.c I
found it as part of openbsd. I assume in modern Linux ecvt must be
part of a larger function but I couldn't find it in the glibc source.
Of course in Unix v5 things were completely straightforward as TUHS
has the file V5/usr/source/s3/ecvt.s
I just want to find all the functions that are still in modern glibc.a
which also existed in Unix v5 libc.a
At 01:04 PM 8/15/2014, Brian Zick wrote:
>Would it still be possible today for someone like me to go out, and find an old teletype terminal (an old ASR or DECwriter or something), set up a phone line and modem and get a roll of paper, and then actually use it to connect to other computers?
Yes, lots of people do it. There is a "Greenkeys" mailing list
http://mailman.qth.net/mailman/listinfo/greenkeys
populated by mostly ham radio RTTY types, but it's also a great archive
of posts about hook-ups and repairs. Yes, there are current-loop
adapters and RS-232 to USB adapters that can be used to connect
to contemporary machines. There are also streaming audio web sites
that send RTTY-style signals if you'd like to emulate your old radio
over the Internet but still use your RTTY audio decoding hardware.
There's also a fellow http://aetherltd.com/ who connects even older teletype
hardware to cell-phone texting.
The Teletype Model 33 was very popular among early computer users
because it was relatively low-priced compared to heavier-duty
teletypes. The old RTTY folks tend to look down their nose at it
because it wasn't as robust as other models.
They routinely huff and puff at recent auction prices for the Model 33,
though, as old computer collectors routinely pay $1,000 for them, while
it's tough to give away the better-built (and heavier!) teletypes.
Last summer I picked up a Western Union-branded Teletype Model 28 KSR
(circa mid-1950s) in near-pristine condition for $50. Almost twenty
years ago I found a Model 33 in a university dumpster.
- John
At 07:46 PM 9/8/2014, you wrote:
>Traffic this evening on the pcc compiler list <pcc.lists.ludd.ltu.se>
>alerted me to the existence of the Software Preservation Group, a
>branch of the Computer History Museum, with a Web site at
>
> http://www.softwarepreservation.org/
Also at http://www.computerhistory.org/groups/spg/ .
It's run by Al Kossow:
http://www.computerhistory.org/staff/Al,Kossow/
He worked at Apple for a long time. His early years were at UW-Milwaukee.
He also frequents the Classic Computer Collector mailing list, a place
where you might acquire and learn to repair the old iron.
- John
The recent UUCP network conversation has me wondering ... is anyone collecting/curating the UUCP maps that represented the way we communicated (outside the ARPANET) from the time of Chesson's paper until the death of comp.mail.maps? Brian Reid's postscript maps were a work of genius; the hand-drawn ASCII maps that predated those are even more wonderful bits of Internet history, let alone art.
--lyndon
> Speaking of using a pipe to an existing command, I originally mis-read the
> code to think there was only _one_ process involved, and that it was buffering
> its output into the pipe before doing the exec() itself - something like this:
>
> pipe(p);
> write_stuff(p[1]);
> close(0);
> dup(p[0]);
> close(p[0]);
> close(p[1]);
> execl("/bin/other", "other", arg, 0);
>
> Which is kind of a hack, but... it does avoid using a second process, although
> the amount of data that can be passed is limited. (IIRC, a pipe will hold at
> most 8 blocks, at least on V6.) Did this hack ever get used in anything?
I didn't notice anybody commenting on the fact that this hack doesn't
work for the purpose--an interactive desk calculator. Running bc then
dc serially defeats interactivity.
The scheme of filling a pipe completely before emptying it is used
in Rob Pike's plan9 editor, sam, to pipe text through some transforming
process. Because the transformer (think sort) may not produce any
output until it has read all its input, sam can't read the result
back until it has finished stuffing the pipe.
Of course sam has to create two pipes, not just one, and it happens
that the initial writer and ultimate reader are the same. But the
basic idea is the same.
Doug
Speaking of things etymological, I've heard two versions of that for
dsw(1).
Delete from Switch Register (delete file whose i-num is in CSR)
Delete Sh*t Work (same, but expressed a bit more robustly)
-- Dave
> From: Dave Horsfall <dave(a)horsfall.org>
> On the *nix systems to which I have access, bc(1) is a standalone
> program on FreeBSD and OSX, but pipes to dc(1) on OpenBSD. I cannot
> check my Penguin box (Ubuntu)
Dude! Trying to answer questions about the origins of BC by looking at
systems this late is like trying to learn Latin by studying Italian! :-)
I looked at the Version 6 source, and it's a bunch of YACC code, but it pulls
the same technique of using a pipe to an instance of DC, viz:
pipe(p);
if (fork()==0) {
close(1);
dup(p[1]);
close(p[0]);
close(p[1]);
yyinit(argc, argv);
yyparse();
exit();
}
close(0);
dup(p[0]);
close(p[0]);
close(p[1]);
execl("/bin/dc", "dc", "-", 0);
There's likely even older versions than the V6 one, but that's the earliest
source I have online on my PC for easy access.
Noel
Hello,
on de.comp.os.unix.shell there is a recent thread about bc(1) which
turned into a discussion about why it is called "bc". dc(1) is pretty
clearly "desk calculator" as by the man page, but the etymology of bc
seems to be unclear.
I've heard the following plausible theories:
- basic calculator (Wikipedia)
- beauty calculator (some people apparently dislike RPN)
- better calculator
- bench calculator (Wikipedia)
- b is the letter d mirrored (RPN vs algebraic)
- bundle calculator (the word "bundle" appears 97 times in bc.y of V6)
...but nobody had a really conclusive argument. Perhaps someone here
remembers the real story?
Thanks,
--
Christian Neukirchen <chneukirchen(a)gmail.com> http://chneukirchen.org
