Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail
From: Don Y <blockedofcourse@foo.invalid>
Newsgroups: comp.arch.embedded
Subject: Return of the Overlays!
Date: Tue, 13 Jan 2026 17:03:54 -0700
Organization: A noiseless patient Spider
Lines: 50
Message-ID: <10k6mhf$3hfn8$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 14 Jan 2026 00:04:00 +0000 (UTC)
Injection-Info: dont-email.me; posting-host="4ed120dabd1a6c7845c143e77381f773"; logging-data="3718888"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/5S0/cFhruw9RZ20ii6tYm"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:HdQmmKPN2ZYOyY7mu450zZklyuw=
Content-Language: en-US
Xref: csiph.com comp.arch.embedded:32451

The use of overlays was a hack to get around small address spaces.
But, it disciplined developers to partition their code into
self-consistent chunks -- you couldn't flip back and forth
between overlaid images (like you could with bank switching).
You had to ensure any indentifiers/labels you needed "now"
were accessible "from here".

In a VMM environment, you don't care -- you just let the
page get faulted in while you wait (assuming it's not presently
in place).

My apps tend to run "forever".  Yet, lots of resources they
use are only transitory; no need for them to persist beyond
the point where they were used.

[Think of initialization code; once done, you're not going
to revisit it until the application is restarted/reloaded]

I'd like to be able to shed resources that are no longer
needed.  But, have some assurances that they truly *aren't*
needed (referenced) going forward.  This lets the system free
up those resources for use by other applications (and runtime
diagnostics, once you know "no one" is using a resource).

[I can do this automatically or let the developer do it "on demand"
by lumping resources in specific sections with judicious use
of linker scripts, etc.  Applications developed with this
in mind will tend to be more resilient because they will tend
to be allowed to continue execution when the system is running
in overload; applications that hold onto unneeded resources
will look "more wasteful" and selected for removal.]

But, there is nothing in the traditional build process that
ensures references from "some point" in the code don't refer
back to some *other* point (that you thought you were done with).

The overlay build process had to ensure THIS overlay didn't refer to
anything in THAT overlay.  (Bankswitching code had to rely on "trampoline"
logic in some shared/persistent area to get from one bank to another,
but, there was nothing prohibiting such references!)

Does anyone still develop with overlays (where the overlay has to
replace the existing overlay at run time)?  Besides personal
familiarity with the codebase, how do you select code portions
to place in each overlay?

Note, this is different than paged VMM where individual pages are
swapped in and out on demand (I have no backing store so once "out",
coming back *in* is costly).