The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* Re: [TUHS] Memory management in Dennis Ritchie's C Compiler
@ 2020-08-25  9:36 Steve Simon
  0 siblings, 0 replies; 46+ messages in thread
From: Steve Simon @ 2020-08-25  9:36 UTC (permalink / raw)
  To: tuhs


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



^ permalink raw reply	[flat|nested] 46+ messages in thread
* Re: [TUHS] Memory management in Dennis Ritchie's C Compiler
@ 2020-08-27  8:37 Paul Ruizendaal
  0 siblings, 0 replies; 46+ messages in thread
From: Paul Ruizendaal @ 2020-08-27  8:37 UTC (permalink / raw)
  To: TUHS main list

Doug,

“In fact Dennis's compiler did not use AID instructions for that purpose.”

Whilst local variables are indeed accessed as an offset from the base pointer, I’m not sure that the above statement is correct. In the V6 compiler (-sp) was certainly used to push arguments to the stack, and when the register allocation overflowed, the interim results were pushed to the stack as well with (-sp).

See c10.c, the case CALL in rcexpr(), the function comarg() and sptab (which is right at the end of table.s)

Links:
https://www.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/c/c10.c
https://www.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/c/table.s

For interim result pushing/popping I refer to the FS and SS macro’s. Dennis discusses these in his “A tour of the C compiler” paper.
https://www.jslite.net/cgi-bin/9995/doc/tip/doc/old-ctour.pdf

Of course this is all implementational detail, not a core design aspect - as Richard Miller showed in his port to the Interdata architecture (including a port of the Ritchie C compiler). Maybe the sentence should have read: "In fact Dennis's compiler did not rely on having AID instructions for that purpose."

Paul

@Warren: at moments like these I really like having the line highlight feature that we discussed before Summer.




^ permalink raw reply	[flat|nested] 46+ messages in thread
* Re: [TUHS] Memory management in Dennis Ritchie's C Compiler
@ 2020-08-26 15:59 Noel Chiappa
  2020-08-26 16:09 ` Warner Losh
                   ` (2 more replies)
  0 siblings, 3 replies; 46+ messages in thread
From: Noel Chiappa @ 2020-08-26 15:59 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: John Cowan

    > That's always true on the PDP-11 and Vax ... because the processor
    > architecture (which has pre-increment and post-decrement instructions,
    > but not their counterparts)

After Doug's message, I carefull re-read this, and I'm not sure it's correct?
The PDP-11 has pre-decrement and post-increment, not the other way around (as
above) - unless I'm misunderstanding what you meant by those terms?

That's why:

	*p++ = 0;

turns (if p is in R2) into

	CLR	(R2)+

R2 is used, and then incremented after it has been used.

   Noel

^ permalink raw reply	[flat|nested] 46+ messages in thread
* Re: [TUHS] Memory management in Dennis Ritchie's C Compiler
@ 2020-08-26 13:24 Doug McIlroy
  2020-08-26 15:41 ` John Cowan
  0 siblings, 1 reply; 46+ messages in thread
From: Doug McIlroy @ 2020-08-26 13:24 UTC (permalink / raw)
  To: tuhs

>     That's always true on the PDP-11 and Vax, no matter what the OS,
>     because the processor architecture (which has pre-increment and
>     post-decrement instructions, but not their counterparts) makes
>     anything but a downward-growing stack unmanageable.

I hadn't heard this urban legend before. A stack is certainly
manageable without auto-increment/decrement (AID) instructions. In
fact Dennis's compiler did not use AID instructions for that purpose.

AID instructions are nice for a LIFO stack, in which a stacked
item disappears as soon as it's used--as do intermediate
results in expression evaluation. But when the stack contains
local variables that are accessed multiple times, the accesses
are offset from the stack pointer. If AID instructions set the
pointer, then the offset of a particular local varies throughout
the code. The compiler can cope with that (I once wrote a
compiler that did so), but a debugger will have a devil of a
time doing a backtrace when the offset of the return address
in each stack frame depends on the location counter.

AID instructions are fine for sequentially accessing arrays, and
in principle Ken's ++ and -- operators can exploit them. Yet
idiomatic C typically wants post-increment and pre-decrement
instructions--the opposite of what DEC offered. Examples:

        char a[N], b[N];
        char *ap = a;
        char *bp = b;
        int i;
        for(i=0; i<N; i++)
                *ap++ = *bp++;

        int a[N], b[N];
        int i = N;
        while(--i >= 0)
                a[i] = b[i];

Doug

^ permalink raw reply	[flat|nested] 46+ messages in thread
* Re: [TUHS] Memory management in Dennis Ritchie's C Compiler
@ 2020-08-17 22:32 Norman Wilson
  2020-08-17 22:55 ` Bakul Shah
                   ` (2 more replies)
  0 siblings, 3 replies; 46+ messages in thread
From: Norman Wilson @ 2020-08-17 22:32 UTC (permalink / raw)
  To: tuhs

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

^ permalink raw reply	[flat|nested] 46+ messages in thread
* Re: [TUHS] Memory management in Dennis Ritchie's C Compiler
@ 2020-08-17 19:51 Noel Chiappa
  0 siblings, 0 replies; 46+ messages in thread
From: Noel Chiappa @ 2020-08-17 19:51 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > 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



^ permalink raw reply	[flat|nested] 46+ messages in thread
* Re: [TUHS] Memory management in Dennis Ritchie's C Compiler
@ 2020-08-17 19:27 Noel Chiappa
  2020-08-17 19:30 ` Larry McVoy
  2020-08-18  0:52 ` Rob Gingell
  0 siblings, 2 replies; 46+ messages in thread
From: Noel Chiappa @ 2020-08-17 19:27 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Jim Geist

    > When did mmap(2) come about?

Pretty sure it's a Berserkleyism. I think it came in with the VM stuff that
DARPA mandated for VAX Unix (for the research project they funded).

   Noel

^ permalink raw reply	[flat|nested] 46+ messages in thread
* Re: [TUHS] Memory management in Dennis Ritchie's C Compiler
@ 2020-08-17  2:02 Noel Chiappa
  2020-08-17 18:02 ` Paul Winalski
  0 siblings, 1 reply; 46+ messages in thread
From: Noel Chiappa @ 2020-08-17  2:02 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > 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

^ permalink raw reply	[flat|nested] 46+ messages in thread
* [TUHS] Memory management in Dennis Ritchie's C Compiler
@ 2020-08-15 21:50 Dibyendu Majumdar
  2020-08-16 15:20 ` arnold
  2020-08-17 16:13 ` Dan Cross
  0 siblings, 2 replies; 46+ messages in thread
From: Dibyendu Majumdar @ 2020-08-15 21:50 UTC (permalink / raw)
  To: The TUHS

Hi,

I have a project to revive 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.

Thanks and Regards
Dibyendu

^ permalink raw reply	[flat|nested] 46+ messages in thread

end of thread, other threads:[~2020-08-27  8:52 UTC | newest]

Thread overview: 46+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-25  9:36 [TUHS] Memory management in Dennis Ritchie's C Compiler Steve Simon
  -- strict thread matches above, loose matches on Subject: below --
2020-08-27  8:37 Paul Ruizendaal
2020-08-26 15:59 Noel Chiappa
2020-08-26 16:09 ` Warner Losh
2020-08-26 19:13   ` Clem Cole
2020-08-26 16:14 ` Jim Geist
2020-08-26 17:31 ` John Cowan
2020-08-26 13:24 Doug McIlroy
2020-08-26 15:41 ` John Cowan
2020-08-17 22:32 Norman Wilson
2020-08-17 22:55 ` Bakul Shah
2020-08-17 23:12 ` Chet Ramey
2020-08-18  6:33 ` arnold
2020-08-17 19:51 Noel Chiappa
2020-08-17 19:27 Noel Chiappa
2020-08-17 19:30 ` Larry McVoy
2020-08-17 19:44   ` Dan Halbert
2020-08-17 19:50   ` Paul Winalski
2020-08-17 22:05     ` Arthur Krewat
2020-08-18  0:52 ` Rob Gingell
2020-08-17  2:02 Noel Chiappa
2020-08-17 18:02 ` Paul Winalski
2020-08-17 18:13   ` Jim Geist
2020-08-17 18:48     ` Paul Winalski
2020-08-17 19:08       ` Jim Geist
2020-08-17 19:28         ` Paul Winalski
2020-08-17 19:35           ` Jim Geist
2020-08-17 19:41             ` Richard Salz
2020-08-17 23:40               ` Steffen Nurpmeso
2020-08-15 21:50 Dibyendu Majumdar
2020-08-16 15:20 ` arnold
2020-08-16 15:27   ` Jim Geist
2020-08-17 16:13 ` Dan Cross
2020-08-17 20:16   ` Dibyendu Majumdar
2020-08-17 20:34     ` Paul Winalski
2020-08-17 20:43       ` Dibyendu Majumdar
2020-08-17 21:05         ` Warner Losh
2020-08-17 22:47         ` Dave Horsfall
2020-08-17 23:06           ` Nemo Nusquam
2020-08-17 21:29     ` Dibyendu Majumdar
2020-08-24 15:58     ` Dan Cross
2020-08-24 17:08       ` John Cowan
2020-08-24 17:15         ` Clem Cole
2020-08-24 17:24           ` Clem Cole
2020-08-24 17:20         ` Dan Cross
2020-08-25 23:06           ` Arthur Krewat

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).