Groups | Search | Server Info | Login | Register


Groups > comp.arch.embedded > #32451

Return of the Overlays!

From Don Y <blockedofcourse@foo.invalid>
Newsgroups comp.arch.embedded
Subject Return of the Overlays!
Date 2026-01-13 17:03 -0700
Organization A noiseless patient Spider
Message-ID <10k6mhf$3hfn8$1@dont-email.me> (permalink)

Show all headers | View raw


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

Back to comp.arch.embedded | Previous | NextNext in thread | Find similar


Thread

Return of the Overlays! Don Y <blockedofcourse@foo.invalid> - 2026-01-13 17:03 -0700
  Re: Return of the Overlays! George Neuner <gneuner2@comcast.net> - 2026-01-14 01:11 -0500
    Re: Return of the Overlays! Don Y <blockedofcourse@foo.invalid> - 2026-01-14 13:39 -0700
      Re: Return of the Overlays! George Neuner <gneuner2@comcast.net> - 2026-01-15 03:06 -0500
        Re: Return of the Overlays! Don Y <blockedofcourse@foo.invalid> - 2026-01-15 03:25 -0700
          Re: Return of the Overlays! George Neuner <gneuner2@comcast.net> - 2026-01-17 01:23 -0500
  Re: Return of the Overlays! John Levine <johnl@taugh.com> - 2026-01-14 20:39 +0000
    Re: Return of the Overlays! Grant Edwards <invalid@invalid.invalid> - 2026-01-14 21:00 +0000
      Re: Return of the Overlays! Don Y <blockedofcourse@foo.invalid> - 2026-01-14 18:55 -0700
    Re: Return of the Overlays! Don Y <blockedofcourse@foo.invalid> - 2026-01-14 18:48 -0700
  Re: Return of the Overlays! Don Y <blockedofcourse@foo.invalid> - 2026-01-25 01:46 -0700
    Re: Return of the Overlays! Don Y <blockedofcourse@foo.invalid> - 2026-01-25 02:10 -0700

csiph-web