The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Dibyendu Majumdar <mobile@majumdar.org.uk>
To: Dan Cross <crossd@gmail.com>
Cc: The TUHS <tuhs@tuhs.org>
Subject: Re: [TUHS] Memory management in Dennis Ritchie's C Compiler
Date: Mon, 17 Aug 2020 21:16:06 +0100	[thread overview]
Message-ID: <CACXZuxeW+FfzNv1me6pUcsXp0WG2HmuMcbEBBg1rX+by3osYoQ@mail.gmail.com> (raw)
In-Reply-To: <CAEoi9W7dNaPrUyAkCPWJGqHpyW7zqHm-Fcn2-vMBbwdKuJjZ-w@mail.gmail.com>

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

  reply	other threads:[~2020-08-17 20:17 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACXZuxeW+FfzNv1me6pUcsXp0WG2HmuMcbEBBg1rX+by3osYoQ@mail.gmail.com \
    --to=mobile@majumdar.org.uk \
    --cc=crossd@gmail.com \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).