The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [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

* Re: [TUHS] Memory management in Dennis Ritchie's C Compiler
  2020-08-15 21:50 [TUHS] Memory management in Dennis Ritchie's C Compiler Dibyendu Majumdar
@ 2020-08-16 15:20 ` arnold
  2020-08-16 15:27   ` Jim Geist
  2020-08-17 16:13 ` Dan Cross
  1 sibling, 1 reply; 46+ messages in thread
From: arnold @ 2020-08-16 15:20 UTC (permalink / raw)
  To: tuhs, mobile

Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:

> 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

There already is a project that revived PCC, probably starting
with the one in 4BSD.

	http://pcc.ludd.ltu.se/

I have a git mirror, just to make things easier for access through
firewalls:

	https://github.com/arnoldrobbins/pcc-revived

Starting from the V10 compiler would be interesting. It was not available
when the above project was started.

HTH,

Arnold

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

* Re: [TUHS] Memory management in Dennis Ritchie's C Compiler
  2020-08-16 15:20 ` arnold
@ 2020-08-16 15:27   ` Jim Geist
  0 siblings, 0 replies; 46+ messages in thread
From: Jim Geist @ 2020-08-16 15:27 UTC (permalink / raw)
  To: arnold; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 929 bytes --]

Do you have a link to the V10 compiler source?

On Sun, Aug 16, 2020 at 11:21 AM <arnold@skeeve.com> wrote:

> Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
>
> > 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
>
> There already is a project that revived PCC, probably starting
> with the one in 4BSD.
>
>         http://pcc.ludd.ltu.se/
>
> I have a git mirror, just to make things easier for access through
> firewalls:
>
>         https://github.com/arnoldrobbins/pcc-revived
>
> Starting from the V10 compiler would be interesting. It was not available
> when the above project was started.
>
> HTH,
>
> Arnold
>

[-- Attachment #2: Type: text/html, Size: 1566 bytes --]

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

* Re: [TUHS] Memory management in Dennis Ritchie's C Compiler
  2020-08-15 21:50 [TUHS] Memory management in Dennis Ritchie's C Compiler Dibyendu Majumdar
  2020-08-16 15:20 ` arnold
@ 2020-08-17 16:13 ` Dan Cross
  2020-08-17 20:16   ` Dibyendu Majumdar
  1 sibling, 1 reply; 46+ messages in thread
From: Dan Cross @ 2020-08-17 16:13 UTC (permalink / raw)
  To: Dibyendu Majumdar; +Cc: The TUHS

[-- Attachment #1: Type: text/plain, Size: 830 bytes --]

On Sat, Aug 15, 2020 at 5:52 PM Dibyendu Majumdar <mobile@majumdar.org.uk>
wrote:

> 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.
>

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. V10 only targets the VAX, and from what I can tell, the two
compilers in use there are LCC and PCC.

From my light skimming of V10 sources, it appears that the various
components of the default C compiler (that is, not LCC) either use
malloc/free or call `sbrk` directly.

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 1205 bytes --]

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

* Re: [TUHS] Memory management in Dennis Ritchie's C Compiler
  2020-08-17 16:13 ` Dan Cross
@ 2020-08-17 20:16   ` Dibyendu Majumdar
  2020-08-17 20:34     ` Paul Winalski
                       ` (2 more replies)
  0 siblings, 3 replies; 46+ messages in thread
From: Dibyendu Majumdar @ 2020-08-17 20:16 UTC (permalink / raw)
  To: Dan Cross; +Cc: The TUHS

On Mon, 17 Aug 2020 at 17:13, Dan Cross <crossd@gmail.com> wrote:
> From my light skimming of V10 sources, it appears that the various components of the default C compiler (that is, not LCC) either use malloc/free or call `sbrk` directly.
>

Yes, it only uses sbrk(). One consequence I think is that sbrk()
expands the process memory without invalidating existing use of memory
- so the code is able to periodically expand heap while retaining all
existing allocations.
A simple workaround I used was to preallocate a heap and just stub out
sbrk() calls - so that works. So in essence given a single chunk of
memory (if large enough - which is still quite small by today's
standards) the compiler manages fine.

However I find this unsatisfactory and would like to improve it. But
it is a bit difficult to understand how the memory is being used.

Memory can be used for declarations, trees (for expressions) and
strings as far as I can tell. Strings actually use the tree
allocation, and just pretend that a node is a string.
It seems that tree memory is allocated in a stack discipline. But what
puzzled me is that when a tree starts, about 512 bytes of memory are
left as gap for declarations to use. I have been trying to think in
what circumstances would you encounter a declaration while parsing an
expression - perhaps cast expressions? Anyway - if a declaration
occurs inside an expression (i.e. tree) then it only has 512 bytes
available. Of course this could be made bigger ... but at the least I
would like to have separate heaps for declarations, trees and strings.

I guess no one really dug into this code - as presumably once PCC came
along the original compiler by Dennis stopped being used.

Thanks and Regards
Dibyendu

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

* Re: [TUHS] Memory management in Dennis Ritchie's C Compiler
  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:29     ` Dibyendu Majumdar
  2020-08-24 15:58     ` Dan Cross
  2 siblings, 1 reply; 46+ messages in thread
From: Paul Winalski @ 2020-08-17 20:34 UTC (permalink / raw)
  To: Dibyendu Majumdar; +Cc: The TUHS

On 8/17/20, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
>
> Yes, it only uses sbrk(). One consequence I think is that sbrk()
> expands the process memory without invalidating existing use of memory
> - so the code is able to periodically expand heap while retaining all
> existing allocations.

If everyone does that, you can call other people's code without fear
of stepping on their memory when you allocate memory in your code.
Using a negative value to decrease the break is more problematic.
malloc() usually uses sbrk() to extend its heap.

When we ported DEC's GEM compilation system to Unix, I used sbrk() to
extend memory and built my own multiple heap allocation scheme on top
of that.  I could have used malloc() to allocate the heap chunks, but
there was no point.  Might as well cut out the middleman.

-Paul W.

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

* Re: [TUHS] Memory management in Dennis Ritchie's C Compiler
  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
  0 siblings, 2 replies; 46+ messages in thread
From: Dibyendu Majumdar @ 2020-08-17 20:43 UTC (permalink / raw)
  To: Paul Winalski; +Cc: The TUHS

On Mon, 17 Aug 2020 at 21:34, Paul Winalski <paul.winalski@gmail.com> wrote:
>
> On 8/17/20, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
> >
> > Yes, it only uses sbrk(). One consequence I think is that sbrk()
> > expands the process memory without invalidating existing use of memory
> > - so the code is able to periodically expand heap while retaining all
> > existing allocations.
>
> If everyone does that, you can call other people's code without fear
> of stepping on their memory when you allocate memory in your code.
> Using a negative value to decrease the break is more problematic.
> malloc() usually uses sbrk() to extend its heap.
>
> When we ported DEC's GEM compilation system to Unix, I used sbrk() to
> extend memory and built my own multiple heap allocation scheme on top
> of that.  I could have used malloc() to allocate the heap chunks, but
> there was no point.  Might as well cut out the middleman.
>

Unfortunately sbrk() is not portable (I am building on Windows with
MSVC too) and as far as I know was even removed from POSIX.

From Wikipedia:
sbrk and brk are considered legacy even by 1997 standards (Single UNIX
Specification v2 or POSIX.1-1998).[5] They were removed in
POSIX.1-2001.[6]

Regards
Dibyendu

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

* Re: [TUHS] Memory management in Dennis Ritchie's C Compiler
  2020-08-17 20:43       ` Dibyendu Majumdar
@ 2020-08-17 21:05         ` Warner Losh
  2020-08-17 22:47         ` Dave Horsfall
  1 sibling, 0 replies; 46+ messages in thread
From: Warner Losh @ 2020-08-17 21:05 UTC (permalink / raw)
  To: Dibyendu Majumdar; +Cc: The TUHS

[-- Attachment #1: Type: text/plain, Size: 1623 bytes --]

On Mon, Aug 17, 2020 at 2:45 PM Dibyendu Majumdar <mobile@majumdar.org.uk>
wrote:

> On Mon, 17 Aug 2020 at 21:34, Paul Winalski <paul.winalski@gmail.com>
> wrote:
> >
> > On 8/17/20, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
> > >
> > > Yes, it only uses sbrk(). One consequence I think is that sbrk()
> > > expands the process memory without invalidating existing use of memory
> > > - so the code is able to periodically expand heap while retaining all
> > > existing allocations.
> >
> > If everyone does that, you can call other people's code without fear
> > of stepping on their memory when you allocate memory in your code.
> > Using a negative value to decrease the break is more problematic.
> > malloc() usually uses sbrk() to extend its heap.
> >
> > When we ported DEC's GEM compilation system to Unix, I used sbrk() to
> > extend memory and built my own multiple heap allocation scheme on top
> > of that.  I could have used malloc() to allocate the heap chunks, but
> > there was no point.  Might as well cut out the middleman.
> >
>
> Unfortunately sbrk() is not portable (I am building on Windows with
> MSVC too) and as far as I know was even removed from POSIX.
>
> From Wikipedia:
> sbrk and brk are considered legacy even by 1997 standards (Single UNIX
> Specification v2 or POSIX.1-1998).[5] They were removed in
> POSIX.1-2001.[6]
>

gnu emacs was the last big user of sbrk. It was one of the few programs
that didn't run on FreeBSD/arm64 which never had sbrk() because it wasn't
possible to sanely implement. It wasn't until recently that gnu emacs fixed
things to not use sbrk()...

Warner

[-- Attachment #2: Type: text/html, Size: 2281 bytes --]

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

* Re: [TUHS] Memory management in Dennis Ritchie's C Compiler
  2020-08-17 20:16   ` Dibyendu Majumdar
  2020-08-17 20:34     ` Paul Winalski
@ 2020-08-17 21:29     ` Dibyendu Majumdar
  2020-08-24 15:58     ` Dan Cross
  2 siblings, 0 replies; 46+ messages in thread
From: Dibyendu Majumdar @ 2020-08-17 21:29 UTC (permalink / raw)
  To: Dan Cross; +Cc: The TUHS

On Mon, 17 Aug 2020 at 21:16, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:

> Memory can be used for declarations, trees (for expressions) and
> strings as far as I can tell. Strings actually use the tree
> allocation, and just pretend that a node is a string.
> It seems that tree memory is allocated in a stack discipline. But what
> puzzled me is that when a tree starts, about 512 bytes of memory are
> left as gap for declarations to use. I have been trying to think in
> what circumstances would you encounter a declaration while parsing an
> expression - perhaps cast expressions? Anyway - if a declaration
> occurs inside an expression (i.e. tree) then it only has 512 bytes
> available. Of course this could be made bigger ... but at the least I
> would like to have separate heaps for declarations, trees and strings.
>

Okay it seems those are undefined symbols encountered in an
expression. Symbols use the same allocation function as declarations.

Regards
Dibyendu

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

* Re: [TUHS] Memory management in Dennis Ritchie's C Compiler
  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
  1 sibling, 1 reply; 46+ messages in thread
From: Dave Horsfall @ 2020-08-17 22:47 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Mon, 17 Aug 2020, Dibyendu Majumdar wrote:

> From Wikipedia:
> sbrk and brk are considered legacy even by 1997 standards (Single UNIX
> Specification v2 or POSIX.1-1998).[5] They were removed in
> POSIX.1-2001.[6]

On a whim, I checked a couple of boxes around here (I haven't used sbrk()
since malloc() came along):

Mac:

     The brk and sbrk functions are historical curiosities left over from ear-
     lier days before the advent of virtual memory management.

FreeBSD:

     The brk() and sbrk() functions are legacy interfaces from before the
     advent of modern virtual memory management.

Both of them come right after the DESCRIPTION header.

-- Dave

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

* Re: [TUHS] Memory management in Dennis Ritchie's C Compiler
  2020-08-17 22:47         ` Dave Horsfall
@ 2020-08-17 23:06           ` Nemo Nusquam
  0 siblings, 0 replies; 46+ messages in thread
From: Nemo Nusquam @ 2020-08-17 23:06 UTC (permalink / raw)
  To: tuhs

On 08/17/20 18:47, Dave Horsfall wrote:
> On Mon, 17 Aug 2020, Dibyendu Majumdar wrote:
>
>> From Wikipedia:
>> sbrk and brk are considered legacy even by 1997 standards (Single UNIX
>> Specification v2 or POSIX.1-1998).[5] They were removed in
>> POSIX.1-2001.[6]
>
> On a whim, I checked a couple of boxes around here (I haven't used sbrk()
> since malloc() came along):
>
> Mac:
>
>     The brk and sbrk functions are historical curiosities left over 
> from ear-
>     lier days before the advent of virtual memory management.
>
> FreeBSD:
>
>     The brk() and sbrk() functions are legacy interfaces from before the
>     advent of modern virtual memory management.
>
> Both of them come right after the DESCRIPTION header.

More whimsy from "man sbrk" on Solaris 10:
     The  use  of mmap(2) is now preferred because it can be used
     portably with all other memory allocation functions and with
     any function that uses other allocation functions.

N.
>
> -- Dave


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

* Re: [TUHS] Memory management in Dennis Ritchie's C Compiler
  2020-08-17 20:16   ` Dibyendu Majumdar
  2020-08-17 20:34     ` Paul Winalski
  2020-08-17 21:29     ` Dibyendu Majumdar
@ 2020-08-24 15:58     ` Dan Cross
  2020-08-24 17:08       ` John Cowan
  2 siblings, 1 reply; 46+ messages in thread
From: Dan Cross @ 2020-08-24 15:58 UTC (permalink / raw)
  To: Dibyendu Majumdar; +Cc: The TUHS

[-- Attachment #1: Type: text/plain, Size: 5780 bytes --]

On Mon, Aug 17, 2020 at 4:16 PM Dibyendu Majumdar <mobile@majumdar.org.uk>
wrote:

> On Mon, 17 Aug 2020 at 17:13, Dan Cross <crossd@gmail.com> wrote:
> > From my light skimming of V10 sources, it appears that the various
> components of the default C compiler (that is, not LCC) either use
> malloc/free or call `sbrk` directly.
>
> Yes, it only uses sbrk().


No, that's not true; or at least it's only partially true. Note that I'm
talking specifically about 10th Edition here.

The compiler is implemented as several cooperating processes, some of which
employ different memory management strategies. Notice, for example, that
`ccom` uses `malloc` but not `sbrk`, while `c2` does the opposite and uses
`sbrk` but not `malloc`. On the other hand, `cpp` does no dynamic memory
allocation and instead has fixed-size symbol tables for preprocessor
definitions etc. Finally, the assembler uses `sbrk` but `ld` uses `malloc`.


> One consequence I think is that sbrk()
> expands the process memory without invalidating existing use of memory
> - so the code is able to periodically expand heap while retaining all
> existing allocations.
> A simple workaround I used was to preallocate a heap and just stub out
> sbrk() calls - so that works. So in essence given a single chunk of
> memory (if large enough - which is still quite small by today's
> standards) the compiler manages fine.
>
> However I find this unsatisfactory and would like to improve it. But
> it is a bit difficult to understand how the memory is being used.
>

So in a nutshell, `sbrk` works by setting the "break" pointer: that is, the
highest usable virtual address in the process's data segment. Stacks may be
at the top of the user portion of the address space; but I'd have to double
check the details. When the process starts up and gets going, one can
discover the initial value of that pointer by executing `sbrk(0)`: since
`sbrk` takes a delta and returns the old value of the break, the return
value will be (basically) the current end of the data segment.

By manipulating the break pointer via `sbrk`, one can cause the kernel to
allocate memory to a process. That memory can then be managed internally
(that is, within the process) via e.g. malloc _or_ a hand-rolled allocator
(e.g., a "bump" allocator): when you want to put something in memory, you
know where the next available pointer is (after the last one you
allocated), you know how much space is available on the heap (since you
allocated it using `sbrk`) and you presumably know how big the thing you
want to store is; if the current pointer + alignment + size of next object
is > break, you allocate more memory using `sbrk` and continue.

There are a couple of approaches you can take to modernize this. The first
you've already discovered: preallocate a heap that you manage with a stub
`sbrk` and be done with it. Another might be to try and find some otherwise
unallocated region of the address space and using `mmap()` to allocate
successive pages to that portion of the address space to simulate `sbrk`;
this may fail if you run into something that's already allocated in one of
those regions.

The most robust way might be the hardest, which is to replace the
`sbrk`-based allocator with calls to e.g. `malloc`. However, looking a
little more closely at 10th Ed's `c2`, for example`, this doesn't seem like
it would be all that bad: `sbrk` is mostly wrapped by a function called
`alloc` that takes an integer number of bytes to allocate and returns a
`struct node *`; the return value is cast to whatever type is needed
though. The use of `struct node *` as the return value is almost certainly
because the compiler was written before `void *` had achieved primacy in
the ANSI C world.

Anyway, I suspect if you simply replaced the guts of `alloc` with `return
malloc(an);` you'd get approximately what you want.

Memory can be used for declarations, trees (for expressions) and
> strings as far as I can tell. Strings actually use the tree
> allocation, and just pretend that a node is a string.
>

Not exactly. The return type of `alloc` is `struct node *`, but that's just
a detail; in the dialect of C that e.g. 10th Ed's PCC is written in, the
return type doesn't matter: it's just a pointer. You can cast it to `char
*` and copy string data there if you want to. I don't know why `struct node
*` was chosen for `alloc`, but I suspect simply convenience.

It seems that tree memory is allocated in a stack discipline. But what
> puzzled me is that when a tree starts, about 512 bytes of memory are
> left as gap for declarations to use. I have been trying to think in
> what circumstances would you encounter a declaration while parsing an
> expression - perhaps cast expressions? Anyway - if a declaration
> occurs inside an expression (i.e. tree) then it only has 512 bytes
> available. Of course this could be made bigger ... but at the least I
> would like to have separate heaps for declarations, trees and strings.
>

This sounds like it's something independent of the allocator and more about
the program's strategy around allocation in general. It's a common trick in
C programs to e.g., allocate the space for some structs plus things that
may be pointed to by those structs in a single allocation; not only does
this cut down on overhead with respect to calling into the allocator, it
also gives you locality.

I don't think you want separate _heaps_ for the things you mention, though
you may want to allocate them separately using independent calls to e.g.
`malloc`. That's fine.

I guess no one really dug into this code - as presumably once PCC came
> along the original compiler by Dennis stopped being used.
>

10th Edition `cc` _is_ `pcc`. I haven't looked at the 7th Ed compiler in
detail.

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 7238 bytes --]

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

* Re: [TUHS] Memory management in Dennis Ritchie's C Compiler
  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:20         ` Dan Cross
  0 siblings, 2 replies; 46+ messages in thread
From: John Cowan @ 2020-08-24 17:08 UTC (permalink / raw)
  To: Dan Cross; +Cc: The TUHS

[-- Attachment #1: Type: text/plain, Size: 648 bytes --]

On Mon, Aug 24, 2020 at 12:00 PM Dan Cross <crossd@gmail.com> wrote:


> Stacks may be at the top of the user portion of the address space; but I'd
> have to double check the details.
>

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.  In OSes without virtual memory like
RSX-11[ABC], RT-11, and mini-Unix/LSX-11, what counts as the top naturally
varies.

Dennis's compiler AFAIK was never extended to anything but the PDP-11, both
as host and target.

[-- Attachment #2: Type: text/html, Size: 1106 bytes --]

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

* Re: [TUHS] Memory management in Dennis Ritchie's C Compiler
  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
  1 sibling, 1 reply; 46+ messages in thread
From: Clem Cole @ 2020-08-24 17:15 UTC (permalink / raw)
  To: John Cowan; +Cc: The TUHS

[-- Attachment #1: Type: text/plain, Size: 540 bytes --]

On Mon, Aug 24, 2020 at 1:09 PM John Cowan <cowan@ccil.org> wrote:

> Dennis's compiler AFAIK was never extended to anything but the PDP-11,
> both as host and target.
>
FWIW: I'm pretty sure that the Teletype Z80 compiler and I know my hacked
68K compiler, used Dennis's V6+ compiler, not PCC as the base.  I think a
couple of the microprocessor compilers that the Purdie folks created did
also.  That said, the MIT RST folks suite for the Nu Machines used PCC and
those became the 'standard' which many of the 'JAWS' ports started.

Clem

[-- Attachment #2: Type: text/html, Size: 1369 bytes --]

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

* Re: [TUHS] Memory management in Dennis Ritchie's C Compiler
  2020-08-24 17:08       ` John Cowan
  2020-08-24 17:15         ` Clem Cole
@ 2020-08-24 17:20         ` Dan Cross
  2020-08-25 23:06           ` Arthur Krewat
  1 sibling, 1 reply; 46+ messages in thread
From: Dan Cross @ 2020-08-24 17:20 UTC (permalink / raw)
  To: John Cowan; +Cc: The TUHS

[-- Attachment #1: Type: text/plain, Size: 1326 bytes --]

On Mon, Aug 24, 2020 at 1:08 PM John Cowan <cowan@ccil.org> wrote:

> On Mon, Aug 24, 2020 at 12:00 PM Dan Cross <crossd@gmail.com> wrote:
>
>> Stacks may be at the top of the user portion of the address space; but
>> I'd have to double check the details.
>>
>
> 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.
>

Ah, but if one has a fixed-size stack that cannot be extended, one can put
it anywhere one wants in the virtual address space. E.g., right after the
program text segment or whatever (effectively using the text as a guard to
detect stack overflow). I don't know why one would want to do that, except
that it makes freeing the virtual address space slightly simpler when the
process exits, but the point is that the Unix choice isn't the only way.
That said, stacks and data growing toward each gives the maximum amount of
flexibility.

In OSes without virtual memory like RSX-11[ABC], RT-11, and
> mini-Unix/LSX-11, what counts as the top naturally varies.
>
> Dennis's compiler AFAIK was never extended to anything but the PDP-11,
> both as host and target.
>

That's my impression, as well.

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 2261 bytes --]

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

* Re: [TUHS] Memory management in Dennis Ritchie's C Compiler
  2020-08-24 17:15         ` Clem Cole
@ 2020-08-24 17:24           ` Clem Cole
  0 siblings, 0 replies; 46+ messages in thread
From: Clem Cole @ 2020-08-24 17:24 UTC (permalink / raw)
  To: John Cowan; +Cc: The TUHS

[-- Attachment #1: Type: text/plain, Size: 669 bytes --]

s/Purdie/Purdue/
s/RST/RTS/

sigh...

On Mon, Aug 24, 2020 at 1:15 PM Clem Cole <clemc@ccc.com> wrote:

>
>
> On Mon, Aug 24, 2020 at 1:09 PM John Cowan <cowan@ccil.org> wrote:
>
>> Dennis's compiler AFAIK was never extended to anything but the PDP-11,
>> both as host and target.
>>
> FWIW: I'm pretty sure that the Teletype Z80 compiler and I know my hacked
> 68K compiler, used Dennis's V6+ compiler, not PCC as the base.  I think a
> couple of the microprocessor compilers that the Purdie folks created did
> also.  That said, the MIT RST folks suite for the Nu Machines used PCC and
> those became the 'standard' which many of the 'JAWS' ports started.
>
> Clem
>

[-- Attachment #2: Type: text/html, Size: 2067 bytes --]

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

* Re: [TUHS] Memory management in Dennis Ritchie's C Compiler
  2020-08-24 17:20         ` Dan Cross
@ 2020-08-25 23:06           ` Arthur Krewat
  0 siblings, 0 replies; 46+ messages in thread
From: Arthur Krewat @ 2020-08-25 23:06 UTC (permalink / raw)
  To: tuhs

[-- Attachment #1: Type: text/plain, Size: 1462 bytes --]

On 8/24/2020 1:20 PM, Dan Cross wrote:
> On Mon, Aug 24, 2020 at 1:08 PM John Cowan <cowan@ccil.org 
> <mailto:cowan@ccil.org>> wrote:
>
>     On Mon, Aug 24, 2020 at 12:00 PM Dan Cross <crossd@gmail.com
>     <mailto:crossd@gmail.com>> wrote:
>
>         Stacks may be at the top of the user portion of the address
>         space; but I'd have to double check the details.
>
>
>     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.
>
>
> Ah, but if one has a fixed-size stack that cannot be extended, one can 
> put it anywhere one wants in the virtual address space. E.g., right 
> after the program text segment or whatever (effectively using the text 
> as a guard to detect stack overflow). I don't know why one would want 
> to do that, except that it makes freeing the virtual address space 
> slightly simpler when the process exits, but the point is that the 
> Unix choice isn't the only way. That said, stacks and data growing 
> toward each gives the maximum amount of flexibility.
>
>     In OSes without virtual memory like RSX-11[ABC], RT-11, and
>     mini-Unix/LSX-11, what counts as the top naturally varies.
>
>
On TOPS-10, I got into the habit of putting the PDL at the end of the 
lowseg. If it ran over, it would die.

ak





[-- Attachment #2: Type: text/html, Size: 3583 bytes --]

^ 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 16:09 ` Warner Losh
@ 2020-08-26 19:13   ` Clem Cole
  0 siblings, 0 replies; 46+ messages in thread
From: Clem Cole @ 2020-08-26 19:13 UTC (permalink / raw)
  To: Warner Losh; +Cc: The Eunuchs Hysterical Society, Noel Chiappa

[-- Attachment #1: Type: text/plain, Size: 260 bytes --]

On Wed, Aug 26, 2020 at 12:09 PM Warner Losh <imp@bsdimp.com> wrote:

> This quirk of the PDP-11 is why I still prefer post-increment and
> pre-decrement in my code... even though there's no chance in hades that my
> code will ever run there...
>
Amen bro ...

[-- Attachment #2: Type: text/html, Size: 782 bytes --]

^ 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
  2020-08-26 16:14 ` Jim Geist
@ 2020-08-26 17:31 ` John Cowan
  2 siblings, 0 replies; 46+ messages in thread
From: John Cowan @ 2020-08-26 17:31 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 600 bytes --]

On Wed, Aug 26, 2020 at 11:59 AM Noel Chiappa <jnc@mercury.lcs.mit.edu>
wrote:

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?
>

Thank you!  Post in haste, repent at leisure; but if I don't post in haste
these days, I won't be able to post at all....



John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
Almost all theorems are true, but almost all proofs have bugs.
        --Paul Pedersen

[-- Attachment #2: Type: text/html, Size: 1175 bytes --]

^ 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
@ 2020-08-26 16:14 ` Jim Geist
  2020-08-26 17:31 ` John Cowan
  2 siblings, 0 replies; 46+ messages in thread
From: Jim Geist @ 2020-08-26 16:14 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 836 bytes --]

You're right. Modes 2 and 3 are post-increment and post-increment deferred.
4 and 5 are pre-decrement and pre-decrement deferred.

On Wed, Aug 26, 2020 at 12:00 PM Noel Chiappa <jnc@mercury.lcs.mit.edu>
wrote:

>     > 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
>

[-- Attachment #2: Type: text/html, Size: 1243 bytes --]

^ 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
  2020-08-26 19:13   ` Clem Cole
  2020-08-26 16:14 ` Jim Geist
  2020-08-26 17:31 ` John Cowan
  2 siblings, 1 reply; 46+ messages in thread
From: Warner Losh @ 2020-08-26 16:09 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 870 bytes --]

On Wed, Aug 26, 2020 at 9:59 AM Noel Chiappa <jnc@mercury.lcs.mit.edu>
wrote:

>     > 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.
>

This quirk of the PDP-11 is why I still prefer post-increment and
pre-decrement in my code... even though there's no chance in hades that my
code will ever run there...

Warner

[-- Attachment #2: Type: text/html, Size: 1341 bytes --]

^ 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, 0 replies; 46+ messages in thread
From: John Cowan @ 2020-08-26 15:41 UTC (permalink / raw)
  To: Doug McIlroy; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1344 bytes --]

On Wed, Aug 26, 2020 at 9:25 AM Doug McIlroy <doug@cs.dartmouth.edu> wrote:

I hadn't heard this urban legend before. A stack is certainly
> manageable without auto-increment/decrement (AID) instructions.


Absolutely.  I should have qualified my remarks by saying "when writing in
assembly language", which was the universal language of all PDP-11
operating systems until Unix.  VMS adopted Bliss (which is what C would be
like if it had come to us through a different dharma line[*]) as its
principal implementation language.


> But when the stack contains
> local variables that are accessed multiple times, the accesses
> are offset from the stack pointer.


Or the frame pointer, which has the advantage that the callee can push
arbitrary stuff on the stack without having to explicitly account for it
later, and the disadvantage that it ties up yet another register when they
are in short supply.

[*] Don't laugh too hard: you yourself have already been mythologized in
precisely this fashion.  See <
http://www.catb.org/~esr/writings/unix-koans/two_paths.html> and <
http://www.catb.org/~esr/writings/unix-koans/zealot.html>.



John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
Mark Twain on Cecil Rhodes: I admire him, I freely admit it,
and when his time comes I shall buy a piece of the rope for a keepsake.

[-- Attachment #2: Type: text/html, Size: 2281 bytes --]

^ 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-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-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
  2 siblings, 0 replies; 46+ messages in thread
From: arnold @ 2020-08-18  6:33 UTC (permalink / raw)
  To: tuhs, norman

norman@oclsc.org (Norman Wilson) wrote:

> 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.

Oh, wouldn't you say that TeX also "followed strict Literate
Programming rules and made a big success of it"?

It's been a while, but I've read the TeX Book.  It's a tour de force;
what Knuth accomplishes in very little space is amazing.

> 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.

I'll agree, worth reading.

Thanks,

Arnold

^ 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
  1 sibling, 0 replies; 46+ messages in thread
From: Rob Gingell @ 2020-08-18  0:52 UTC (permalink / raw)
  To: tuhs

On 8/17/2020 12:27 PM, Noel Chiappa wrote:
>      > 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).

[What follows verges on being COFF-ish].

mmap() is descended from TENEX's PMAP, which is a simplified descendant 
of the file/process memory integration provided by Multics. (Other 
antecedents I leave to more informed genealogists than I.)

A Multics process had an address space made up of segments (files) which 
were paged (vs. swapped). Segments were what programs dealt with, paging 
was done to manage the physical resources of the system.

TENEX simplified everything to pages, address spaces were composed by 
mapping pages of the address space to files. Programs operated on pages, 
which were also what the system used to manage memory. Files were 
described by page tables, address spaces were described by page tables, 
lots of symmetry around things of size 512 (9 bits) (page size, page 
table size, page-tables of page tables for long files). File size and 
file system system capacities were announced in pages. Very harmonious, 
but uniquely so.

Multics was most definitely not portable due to its unique hardware 
constraints (Intel's 432 being an exception). TENEX only required paging 
support but was not portable from PDP-10s which were not keeping up with 
the world's movement to computers that were increasingly 4-bits shy of a 
word (i.e., not 36 bits). Many more considerations apply but to keep it 
only verging on COFF-ish will stop there -- going deeper would be best 
done in person with tankards of ale.

TENEX systems were ARPA's workhorse systems in the 1970s, supporting 
numerous research programs and sites. The file/process memory 
integration was a valued capability among the community (though, 
honestly, it was one of these things everyone said should exist though 
few actually used directly). Even though DEC provided commercial support 
by adopting TENEX as TOPS-20 and selling 1000s of them (vs. the 10s of 
them made via BBN + PARC's MAXC), as the 70's progressed it was apparent 
that things were going to shift elsewhere. DEC was hesitant about 
further 36-bit development and UNIX's arrival provided an intellectual 
migration path for the community that commercial alternatives didn't. If 
only UNIX could just accumulate some of the capabilities expected in the 
ARPA world, like file/process memory integration (ironically, one of the 
Multics complexities from which UNIX had departed.)

mmap() is a simplified, portable form of PMAP. It was written into the 
specifications for ARPA via Bill Joy as Larry McVoy and Noel Chiappa 
noted. It existed only as a specification for quite a while. First 
implementations were as a device-driver level function for things like 
frame-buffers for use by window systems and perhaps for other devices 
I'm not remembering at the moment.

The general file/process memory integration aspect didn't happen prior 
to SunOS 4.0 though I seem to recall some special-case subsets being 
tried by other UNIX implementations and also more generally with Mach, I 
believe. The gestalt of file/process memory integration in 4.0 was very 
TENEX-like in how it was used in fork()/exec()/brk()/shared libraries. 
4.0 differed from TENEX in being portable, launched on heterogeneous 
hardware (VAX, 68010 (Sun-2's), 68020 (Sun-3's), 386 (386i), SPARC 
(Sun-4) all except the VAX being actively supported Sun products at the 
time), and a general-networking view of how coherency should work (vs. a 
clustered-network such as TOPS-20's CFS.)

(As a hysterical note, every release of (BSD-based) SunOS through 4.0 
was always ported to the VAX as a portability check. It also provied us 
utility as a convenient way to quickly check for "but it works on the 
VAX" problems with new things gotten from UCB. Prior to 4.0, given that 
the BSD-based implementation basically tried to mimic a VAX internally, 
that wasn't too bad. But the VAXectomy that occurred in 4.0 made that 
much more daunting, and so the 4.0 VAX port was a pretty half-hearted 
attempt and the last new task for the 11/750 that faded deeper and 
deeper into the back of the lab over time.)

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

* Re: [TUHS] Memory management in Dennis Ritchie's C Compiler
  2020-08-17 19:41             ` Richard Salz
@ 2020-08-17 23:40               ` Steffen Nurpmeso
  0 siblings, 0 replies; 46+ messages in thread
From: Steffen Nurpmeso @ 2020-08-17 23:40 UTC (permalink / raw)
  To: Richard Salz; +Cc: The Eunuchs Hysterical Society, Noel Chiappa

Richard Salz wrote in
 <CAFH29tpbNrUKVP2hp25wdu9BYCxQr+RrmcWJ8F+SbtwsGE4VKw@mail.gmail.com>:
 |Apache has the "pool" concept, per-request storage; there are a few

And BSD Mail had the "stringdope" of Kurt Shoens from the very
start in 1978.  It serves allocations of various size until reset
time.  (Different to the Apache thing it does not support
destructor calls -- if i recall the Apache stuff, i have looked
into that two decades ago.)

I personally had objects caches and fluctuating object caches
backed by generic C types

        pub GOCache(uir _objsz, uir _growby=8-1);
        ...
        pub uir count(void) const { return(m_count); }
        pub void *alloc(void);
        pub GOCache &free(void *_ptr);
        pub GOCache &clear(void);
        pub GOCache &swap(GOCache &_t);

and used via all-inline template wrappers

  template<class T> class OCache : private GOCache{
    ...
    OCache(uir _growby=8-1) : Super(szof(T), _growby) {}
    ...
    pub T *newObject(void) { return(SF_newHeap(T, Super::alloc())); }
    pub OCache &delObject(T *_tptr){
      _AssertRetThis(_tptr != NIL);
      _tptr->~T();
      return(s(Me&,Super::free(_tptr)));
    }
    ...

The difference was that the normal could not free individual
chunks, the other could

      pri union Atom{
        Chunk   *owner; // used
        Atom    *next;  // free
      }SF_CC_PACKED;

      pri struct Chunk{
        Chunk   *right;
        Atom    *free;  // freelist
        ui1     *top;   // cast point or NIL if full
        uir     count;  // user pointers this Chunk
      }SF_CC_PACKED;

vs

      pri struct Atom{
        Atom    *next;
      }SF_CC_PACKED;

      pri struct Chunk{
        Chunk   *right;
        ui1     *top;   // cast point or NIL if full
      }SF_CC_PACKED;

(here the free Atom free list was part of the cache object).
That even worked out fine to serve nodes on hashmap and list
objects, in practice.

 |versions:
 |   https://commons.apache.org/proper/commons-pool/ (java)
 |   http://www.apachetutor.org/dev/pools (C server)

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

^ 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
@ 2020-08-17 23:12 ` Chet Ramey
  2020-08-18  6:33 ` arnold
  2 siblings, 0 replies; 46+ messages in thread
From: Chet Ramey @ 2020-08-17 23:12 UTC (permalink / raw)
  To: Norman Wilson, tuhs

On 8/17/20 6:32 PM, Norman Wilson wrote:

> 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.

Arenas.

http://drhanson.s3.amazonaws.com/storage/documents/fastalloc.pdf

I'm pretty sure this is the literate programming variant Fraser and
Hanson used for the book:

https://www.cs.tufts.edu/~nr/pubs/lpsimp.pdf

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

^ 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
  2020-08-17 23:12 ` Chet Ramey
  2020-08-18  6:33 ` arnold
  2 siblings, 0 replies; 46+ messages in thread
From: Bakul Shah @ 2020-08-17 22:55 UTC (permalink / raw)
  To: Norman Wilson; +Cc: tuhs

On Aug 17, 2020, at 3:32 PM, Norman Wilson <norman@oclsc.org> wrote:
> 
> 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.

Didn't lcc use iburg or some such to generate the
code generator, which could do such things?

> 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.

Agree. They used noweb. Probably with a troff backend?

^ 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:50   ` Paul Winalski
@ 2020-08-17 22:05     ` Arthur Krewat
  0 siblings, 0 replies; 46+ messages in thread
From: Arthur Krewat @ 2020-08-17 22:05 UTC (permalink / raw)
  To: tuhs

On 8/17/2020 3:50 PM, Paul Winalski wrote:
> VAX/VMS had the equivalent of mmap(2) back in 1978.  You can specify a
> range of contiguous pages in virtual memory and associate that with a
> (page-aligned) range of blocks in a file.  The blocks in the file act
> as backing store for the virtual memory.
I, and my boss, took advantage of that while converting his database 
software from TOPS-10 to VMS.

His TOPS-10 implementation used various ways to optimize I/O from/to 
disk. On VMS, our benchmarks showed that as long as we understood the 
paging size, performance was about the same. RP06 vs. I think something 
bigger. Maybe RP07. But even still, it proved the operating system 
virtual memory system was up to the task.

I seem to remember there was a way to sync a page after you wrote it 
just to make sure it was committed to disk. It worked so well that I 
also seem to recall that we used some of that file space as heap.

art k.


^ 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:30 ` Larry McVoy
  2020-08-17 19:44   ` Dan Halbert
@ 2020-08-17 19:50   ` Paul Winalski
  2020-08-17 22:05     ` Arthur Krewat
  1 sibling, 1 reply; 46+ messages in thread
From: Paul Winalski @ 2020-08-17 19:50 UTC (permalink / raw)
  To: Larry McVoy; +Cc: tuhs, Noel Chiappa

On 8/17/20, Larry McVoy <lm@mcvoy.com> wrote:
> On Mon, Aug 17, 2020 at 03:27:15PM -0400, Noel Chiappa wrote:
[regarding mmap(2)]
>
> Bill Joy imagined it, the prototype is in one the 4.x BSD releases.
> Sun (Joe Moran) actually implemented it first in any Unix variant.
> It's possible the concept existed in some other OS but I'm not aware
> of it.
>
VAX/VMS had the equivalent of mmap(2) back in 1978.  You can specify a
range of contiguous pages in virtual memory and associate that with a
(page-aligned) range of blocks in a file.  The blocks in the file act
as backing store for the virtual memory.  VMS also has a system call
$CRETVA (create virtual address space) that lets you associate a VA
range using the system page file as backing store.  The VMS image
activator (runtime loader in Unix-speak) used these primitives to load
program images into virtual memory.  More than one process can map the
same region of a file.  This is how sharing of read-only program
segments such as .text is implemented.

I think Burroughs OSes had this concept even before VMS.

There is also $EXPREG (expand address region), which is more or less
equivalent to sbrk().

-Paul W.

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

* Re: [TUHS] Memory management in Dennis Ritchie's C Compiler
  2020-08-17 19:30 ` Larry McVoy
@ 2020-08-17 19:44   ` Dan Halbert
  2020-08-17 19:50   ` Paul Winalski
  1 sibling, 0 replies; 46+ messages in thread
From: Dan Halbert @ 2020-08-17 19:44 UTC (permalink / raw)
  To: tuhs

On 8/17/20 3:30 PM, Larry McVoy wrote:
> On Mon, Aug 17, 2020 at 03:27:15PM -0400, Noel Chiappa wrote:
>>      > 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).
> Bill Joy imagined it, the prototype is in one the 4.x BSD releases.
> Sun (Joe Moran) actually implemented it first in any Unix variant.
> It's possible the concept existed in some other OS but I'm not aware
> of it.
I have a clear memory of having a discussion with Bill Joy about the 
idea of vread(2) and vwrite(2) when we were both grad students at 
Berkeley. I remember we were eating sausages from Top Dog and sitting 
outside Etcheverry Hall on or near the grassy plaza. I think vfork may 
have already existed, and we were talking about adding some kind of 
memory-mapped file I/O. I think I suggested the actual names, as a 
parallel to vfork. Some of my thinking might have come from my 
experience with TENEX while working summers at BBN. I was just a 
sounding board; I wasn't implementing any of this. vread and vwrite were 
in BSD4.1, but dropped in 4.2 (so my Googling says). I think it became 
clear later that mmap was an easier concept than the initial vread and 
vwrite ideas.

Dan H.

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

* Re: [TUHS] Memory management in Dennis Ritchie's C Compiler
  2020-08-17 19:35           ` Jim Geist
@ 2020-08-17 19:41             ` Richard Salz
  2020-08-17 23:40               ` Steffen Nurpmeso
  0 siblings, 1 reply; 46+ messages in thread
From: Richard Salz @ 2020-08-17 19:41 UTC (permalink / raw)
  To: Jim Geist; +Cc: The Eunuchs Hysterical Society, Noel Chiappa

[-- Attachment #1: Type: text/plain, Size: 187 bytes --]

Apache has the "pool" concept, per-request storage; there are a few
versions:
   https://commons.apache.org/proper/commons-pool/ (java)
   http://www.apachetutor.org/dev/pools (C server)

[-- Attachment #2: Type: text/html, Size: 397 bytes --]

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

* Re: [TUHS] Memory management in Dennis Ritchie's C Compiler
  2020-08-17 19:28         ` Paul Winalski
@ 2020-08-17 19:35           ` Jim Geist
  2020-08-17 19:41             ` Richard Salz
  0 siblings, 1 reply; 46+ messages in thread
From: Jim Geist @ 2020-08-17 19:35 UTC (permalink / raw)
  To: Paul Winalski; +Cc: The Eunuchs Hysterical Society, Noel Chiappa

[-- Attachment #1: Type: text/plain, Size: 1060 bytes --]

True, but zones and HeapAlloc do a fair bit of work to handle objects of
multiple sizes. If you're partitioning up a page and you know every object
on the page is 8 or 16 or 48 bytes, it's MUCH simpler. And a lot of the
data structures in a compiler tend to be small-tens-of-bytes nodes.

On Mon, Aug 17, 2020 at 3:28 PM Paul Winalski <paul.winalski@gmail.com>
wrote:

> On 8/17/20, Jim Geist <velocityboy@gmail.com> wrote:
> > When did mmap(2) come about? Another thing I've seen is building a small
> > block allocator on top of that. You can guarantee that all your objects
> are
> > nicely collected into the same set of pages for locality with very little
> > overhead.
> >
> mmap(2) certainly can be used to allocate blocks for the mini-heap
> itself, but you still have to write your own equivalents of malloc()
> and free() to allocate data structures within the mini-heap.  The nice
> thing about VMS heap zones and Microsoft's private heaps is that you
> get the malloc()/free() layer off-the-shelf; you don't have to roll
> your own.
>
> -Paul W.
>

[-- Attachment #2: Type: text/html, Size: 1488 bytes --]

^ 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-17 19:44   ` Dan Halbert
  2020-08-17 19:50   ` Paul Winalski
  2020-08-18  0:52 ` Rob Gingell
  1 sibling, 2 replies; 46+ messages in thread
From: Larry McVoy @ 2020-08-17 19:30 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: tuhs

On Mon, Aug 17, 2020 at 03:27:15PM -0400, Noel Chiappa wrote:
>     > 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).

Bill Joy imagined it, the prototype is in one the 4.x BSD releases.
Sun (Joe Moran) actually implemented it first in any Unix variant.
It's possible the concept existed in some other OS but I'm not aware
of it.

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

* Re: [TUHS] Memory management in Dennis Ritchie's C Compiler
  2020-08-17 19:08       ` Jim Geist
@ 2020-08-17 19:28         ` Paul Winalski
  2020-08-17 19:35           ` Jim Geist
  0 siblings, 1 reply; 46+ messages in thread
From: Paul Winalski @ 2020-08-17 19:28 UTC (permalink / raw)
  To: Jim Geist; +Cc: The Eunuchs Hysterical Society, Noel Chiappa

On 8/17/20, Jim Geist <velocityboy@gmail.com> wrote:
> When did mmap(2) come about? Another thing I've seen is building a small
> block allocator on top of that. You can guarantee that all your objects are
> nicely collected into the same set of pages for locality with very little
> overhead.
>
mmap(2) certainly can be used to allocate blocks for the mini-heap
itself, but you still have to write your own equivalents of malloc()
and free() to allocate data structures within the mini-heap.  The nice
thing about VMS heap zones and Microsoft's private heaps is that you
get the malloc()/free() layer off-the-shelf; you don't have to roll
your own.

-Paul W.

^ 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 18:48     ` Paul Winalski
@ 2020-08-17 19:08       ` Jim Geist
  2020-08-17 19:28         ` Paul Winalski
  0 siblings, 1 reply; 46+ messages in thread
From: Jim Geist @ 2020-08-17 19:08 UTC (permalink / raw)
  To: Paul Winalski; +Cc: The Eunuchs Hysterical Society, Noel Chiappa

[-- Attachment #1: Type: text/plain, Size: 1880 bytes --]

When did mmap(2) come about? Another thing I've seen is building a small
block allocator on top of that. You can guarantee that all your objects are
nicely collected into the same set of pages for locality with very little
overhead.

On Mon, Aug 17, 2020 at 2:48 PM Paul Winalski <paul.winalski@gmail.com>
wrote:

> On 8/17/20, Jim Geist <velocityboy@gmail.com> wrote:
> > You beat me to my response. malloc/free are great for long running
> > processes where memory can't just infinitely increase, but there's a ton
> of
> > stuff in a compiler -- types, expressions, symbols -- that survives until
> > the process exits. There's benefit in both space (because you don't have
> to
> > add headers to the blocks as malloc() does, so free() can work) and time
> to
> > doing it this way.
> >
> The other issue is locality of reference.  Data structures such as the
> symbol table get built up gradually as the compilation processes each
> routine.  Typically the symbol table is stored as a hash table where
> each entry is a pointer to the actual symbol table entry data
> structure.  If you malloc() each symbol table entry individually, they
> can end up scattered all over the virtual address space.  It's not as
> important these days, when main memory is measured in gigabytes, but
> back when machines had less real memory, the scattering could lead to
> excessive page faulting.  Much better to allocate symbol table entries
> in chunks, and the easiest way to do that is to give the symbol table
> its own mini-heap.
>
> VMS implemented the mini-heap concept (VMS calls them zones) back in
> its first release in 1978.  Dave Cutler took the concept to Windows NT
> (Microsoft calls them private heaps).  Lots of applications have built
> their own mini-heap system on top of sbrk(), but has a library of
> mini-heap-type APIs ever been distributed on Unix?
>
> -Paul W.
>

[-- Attachment #2: Type: text/html, Size: 2355 bytes --]

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

* Re: [TUHS] Memory management in Dennis Ritchie's C Compiler
  2020-08-17 18:13   ` Jim Geist
@ 2020-08-17 18:48     ` Paul Winalski
  2020-08-17 19:08       ` Jim Geist
  0 siblings, 1 reply; 46+ messages in thread
From: Paul Winalski @ 2020-08-17 18:48 UTC (permalink / raw)
  To: Jim Geist; +Cc: The Eunuchs Hysterical Society, Noel Chiappa

On 8/17/20, Jim Geist <velocityboy@gmail.com> wrote:
> You beat me to my response. malloc/free are great for long running
> processes where memory can't just infinitely increase, but there's a ton of
> stuff in a compiler -- types, expressions, symbols -- that survives until
> the process exits. There's benefit in both space (because you don't have to
> add headers to the blocks as malloc() does, so free() can work) and time to
> doing it this way.
>
The other issue is locality of reference.  Data structures such as the
symbol table get built up gradually as the compilation processes each
routine.  Typically the symbol table is stored as a hash table where
each entry is a pointer to the actual symbol table entry data
structure.  If you malloc() each symbol table entry individually, they
can end up scattered all over the virtual address space.  It's not as
important these days, when main memory is measured in gigabytes, but
back when machines had less real memory, the scattering could lead to
excessive page faulting.  Much better to allocate symbol table entries
in chunks, and the easiest way to do that is to give the symbol table
its own mini-heap.

VMS implemented the mini-heap concept (VMS calls them zones) back in
its first release in 1978.  Dave Cutler took the concept to Windows NT
(Microsoft calls them private heaps).  Lots of applications have built
their own mini-heap system on top of sbrk(), but has a library of
mini-heap-type APIs ever been distributed on Unix?

-Paul W.

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

* Re: [TUHS] Memory management in Dennis Ritchie's C Compiler
  2020-08-17 18:02 ` Paul Winalski
@ 2020-08-17 18:13   ` Jim Geist
  2020-08-17 18:48     ` Paul Winalski
  0 siblings, 1 reply; 46+ messages in thread
From: Jim Geist @ 2020-08-17 18:13 UTC (permalink / raw)
  To: Paul Winalski; +Cc: The Eunuchs Hysterical Society, Noel Chiappa

[-- Attachment #1: Type: text/plain, Size: 1347 bytes --]

You beat me to my response. malloc/free are great for long running
processes where memory can't just infinitely increase, but there's a ton of
stuff in a compiler -- types, expressions, symbols -- that survives until
the process exits. There's benefit in both space (because you don't have to
add headers to the blocks as malloc() does, so free() can work) and time to
doing it this way.

On Mon, Aug 17, 2020 at 2:03 PM Paul Winalski <paul.winalski@gmail.com>
wrote:

> On 8/16/20, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:
> >
> > 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:
>
> This is very common in compilers.  Both the DEC/Compaq and Intel
> compilers manage heap memory this way. Each particular phase or pass
> of a compiler tends to build its on set of data structures in heap,
> and then free the whole mess when the phase/pass is done.  malloc/free
> doesn't fit the model very well because you have to free each
> structure individually, and for more persistent structures you don't
> get very good locality of reference.  What works better is to use a
> multitude of mini-heaps that can be freed up all in one go.
>
> -Paul W.
>

[-- Attachment #2: Type: text/html, Size: 1801 bytes --]

^ 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
  2020-08-17 18:13   ` Jim Geist
  0 siblings, 1 reply; 46+ messages in thread
From: Paul Winalski @ 2020-08-17 18:02 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: tuhs

On 8/16/20, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:
>
> 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:

This is very common in compilers.  Both the DEC/Compaq and Intel
compilers manage heap memory this way. Each particular phase or pass
of a compiler tends to build its on set of data structures in heap,
and then free the whole mess when the phase/pass is done.  malloc/free
doesn't fit the model very well because you have to free each
structure individually, and for more persistent structures you don't
get very good locality of reference.  What works better is to use a
multitude of mini-heaps that can be freed up all in one go.

-Paul W.

^ 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

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-15 21:50 [TUHS] Memory management in Dennis Ritchie's C Compiler 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
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-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 19:51 Noel Chiappa
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-25  9:36 Steve Simon
2020-08-26 13:24 Doug McIlroy
2020-08-26 15:41 ` John Cowan
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-27  8:37 Paul Ruizendaal

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).