From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Fri, 30 May 1997 00:10:52 -0400
From: ken@achille.cs.bell-labs.com ken@achille.cs.bell-labs.com
Subject: No subject
Topicbox-Message-UUID: 5b710634-eac8-11e9-9e20-41e7f4b1d025
Message-ID: <19970530041052.tsbzeTIfghDufVVsboueJI8on9oa23trHU8-NLgIbys@z>

> As I recall, 8l doesn't use malloc and free; it just allocates
> space on the heap and never frees it.  It tends to walk some
> fairly large lists multiple times, which adds to the thrashing
> behaviour when there isn't enough RAM.  I remember being told
> that the justification for this was efficiency; when you have
> the RAM, it is a lot faster to avoid the extra overheads of
> using a real allocator, or so the argument goes.

> I'm starting to wonder if it mightn't be a bad idea to try and
> change the way 8l does its allocation, to make compiling
> these programs possible on machines which don't have huge
> amounts of RAM.  Has anyone else looked at the linker internals
> and have an opinion on this?  It's been a while since I looked
> in there myself, so I don't have a really good feel for how
> much memory is being wasted, or how much locality of reference
> there is, or indeed how easy it would be to figure out
> what needs to be freed...

8c allocates memory and doesnt free it when unused. 8l doesn't.
almost all of the allocated memory in 8l is used in a linked
list of instructions. i doubt if you will save any space by
calling malloc and free.

if there is any space to be had, it is from rearranging the
structures Adr and Prog (which contains 2 Adr's) to be
more specific to individual instruction types. (ie most
instructions have only one full address with the other
address a register.)