I am fairly sure the interdata port from Wollongong used the v6 c compiler, and this lived on in the “official” v7 port from perkin elmer, it still used the v6 compiler.
i remember the pain of the global namespace for structure members.
-Steve
> >> Even high-school employees could make lasting contributions. I am
> >> indebted to Steve for a technique he conceived during his first summer
> >> assignment: using macro definitions as if they were units of associative
> >> memory. This view of macros stimulated previously undreamed-of uses.
>
> > Can you give some examples of what this looked like?
>
See attached for an answer to Arnold's question
Doug
> Did the non-Unix people also pull pranks like the watertower?
One of my favorites was by John Kelly, a Texas original,
who refused the department-head perk of a rug so he
could stamp his cigarettes out on the vinyl floor.
John came from Visual and Acoustics Research, where
digital signal processing pressed the frontiers of
computing. Among his publications was the completely
synthetic recording of "Daisy, Daisy" released
circa 1963.
Kelly electrified the computer center with a
blockbuster prank a year or two before that. As
was typical of many machine rooms, a loudspeaker
hooked to the low-order bit of the accumulator
played gentle white noise in the background. The
noise would turn into a shriek when the computer
got into a tight loop, calling the operators to
put the program out of its misery.
Out of the blue one day, the loudspeaker called
for help more articulately: "Help, I'm caught in
a loop. Help, I'm caught in a loop. ..." it
intoned in a slow Texas drawl. News of the talking
computer spread instantly and folks croweded into
the machine room to marvel before the operators
freed the poor prisoner.
Doug
Dan Cross:
I'll confess I haven't looked _that_ closely, but I rather imagine that the
V10 compiler is a descendant of PCC rather than Dennis's V6/V7 PDP-11
compiler.
====
Correct. From 8/e to the end of official Research UNIX,
cc was pcc2 with a few research-specific hacks.
As Dan says, lcc was there too, but not used a lot.
I'm not sure which version of lcc it was; probably it
was already out-of-date.
In my private half-backed 10/e descendant system, which
runs only on MicroVAXes in my basement, cc is an lcc
descendant instead. I took the lcc on which the book
was based and re-ported it to the VAX to get an ISO-
compliant C compiler, and made small changes to libc
and /usr/include to afford ISO-C compliance there too.
The hardest but most-interesting part was optimizing.
lcc does a lot of optimization work by itself, and
initially I'd hoped to dispense with a separate c2
pass entirely, but that turns out not to be feasible
on machines like the VAX or the PDP-11: internally
lcc separates something like
c = *p++;
into two operations
c = *p;
p++;
and makes two distinct calls to the code generator.
To sew them back together from
cvtbl (p),c
incl p
to
cvtbl (p)+,c
requires external help; lcc just can't see that
what it thinks of as two distinct expressions
can be combined.
It's more than 15 years since I last looked at any
of this stuff, but I vaguely remember that lcc has
its own interesting (but ISO/POSIX-compatible)
memory-allocation setup. It allows several nested
contexts' worth of allocation, freeing an inner
context when there's no longer any need for it.
For example, once the compiler has finished with
a function and has no further need for its local
symbols, it frees the associated memory.
See the lcc book for details. Read the book anyway;
it's the one case I know of in which the authors
followed strict Literate Programming rules and made
a big success of it. Not only is the compiler well-
documented, but the result is a wonderful tour
through the construction and design decisions of a
large program that does real work.
Norman Wilson
Toronto ON
> From: Dibyendu Majumdar
> the C compiler from V7/V10. I wanted to check if anyone here knows
> about the memory management in the compiler (c0 only for now). I am
> trying to migrate the memory management to malloc/free but I am
> struggling to understand exactly how memory is being managed.
Well, I don't know much about the V7 compiler; the V6 one, which I have looked
at, doesn't (except for the optimizer, C2) use allocated memory at all.
The V7 compiler seems to use sbrk() (the system call to manage the location of
the end of a process' data space), and manage the additional data space
'manually'; it does not seem to use a true generic heap. See gblock() in
c01.c:
https://minnie.tuhs.org//cgi-bin/utree.pl?file=V7/usr/src/cmd/c/c01.c
which seems to use two static variables (curbase and coremax) to manage
that additional memory:
p = curbase;
if ((curbase =+ n) >= coremax) {
if (sbrk(1024) == -1) {
error("Out of space");
exit(1);
}
coremax =+ 1024;
}
return(p);
My guess is that there's no 'free' at all; each C source file is processed
by a new invocation of C0, and the old 'heap' is thrown away when the
process exits when it gets to the EOF.
Noel
> From: Larry
> It's possible the concept existed in some other OS but I'm not aware of
> it.
It's pretty old. Both TENEX and ITS had the ability to map file pages into a
process' address space. Not sure if anything else of that vintage had it (not
sure what other systems back then _had_ paging, other than Atlas; those two
both had custom KA10 homebrew hardware mods to support paging). Of course,
there's always Multics... (sorry, Ken :-).
Noel
fyi warner,
in your talk, you referred to Alex Fraser at bell labs.
he was my first director, and always went by “sandy”.
i asked my wife (who was a secretary at the time) and she
said he was occasionally referred to as Alex. certainly, every
time i saw anything written by him or references to a talk by him
always used “sandy”.
andrew
>
> Message: 6
> Date: Fri, 5 Jun 2020 16:51:27 -0600
> From: Warner Losh <imp(a)bsdimp.com>
> To: The Eunuchs Hysterical Society <tuhs(a)tuhs.org>
> Subject: [TUHS] My BSDcan talk
> Message-ID:
> <CANCZdfpq8tiDYe2iVeFh1h0VMDK+4B=kXuGSJ3iNmtjbzHQT6Q(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> OK. Must be off my game... I forgot to tell people about my BSDcan talk
> earlier today. It was streamed live, and will be online in a week or
> three...
>
> It's another similar to the last two. I've uploaded a version to youtube
> until the conference has theirs ready. It's a private link, but should work
> for anybody that has it. Now that I've given my talk it's cool to share
> more widely... https://www.youtube.com/watch?v=NRq8xEvFS_g
>
> The link at the end is wrong. https://github.com/bsdimp/bsdcan2020-demos is
> the proper link.
>
> Please let me know what you think.
>
> Warner
>
Just saw your BSDcan talk. Great stuff, so much progress in the last five years. Just wanna say thanks. When I started looking into ancient systems, it was hard finding anything coherent on the historical side beyond manuals and this list (thankful to Warren & co for the list). Your talk is packed with interesting information and really pulls together the recent pieces.
Great job, Warner.
I needed to look up something in the Bell System Technical Journal
(Wikipedia didn't have it) and discovered that the old Alcatel-Lucent
site that used to host a free archive of BSTJ no longer seems extant.
(No surprise, the Web is nothing if not ephemeral.)
After a bit of Googling, I did find that the archives are now residing
at <https://archive.org/details/bstj-archives> and found what I was
looking for there.
Hope others find this link useful. At least until it too "sublimaates".
Kirk McKusick
