Groups | Search | Server Info | Login | Register

Groups > comp.arch.embedded > #32452

Re: Return of the Overlays!

Show all headers | View raw

Hi Don,


On Tue, 13 Jan 2026 17:03:54 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

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

Granted most existing compilers do not understand the concept of
"overlay" per se, but they do certainly understand both definition and
execution scope [in many languages these are identical, but in some
they can be different].

The problems with overlays almost all are related to closures and
[escape] continuations - in C terms: stored function pointers and
exceptions (or longjmp).



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

Just scope handling. 

The issue with (classic) C was it had only global and local scopes.
Supporting overlays required the addition of non-global-non-local
scopes [at the load module level at least], and a bit of runtime magic
behind the scenes to load/unload them.


>Does anyone still develop with overlays ...

I haven't seen an overlay compiler since 8-bit.  Of course, 8-bit
cpus/mpus still are used in the embedded world.


More broadly: explicity loaded DLLs [ using dlopen()/dlsym(),
LoadLibrary()/GetProcAddress(), etc. ] could be considered modern
moral equivalents of overlays.  

Though they may not share memory (or other resources) and their
coming/going is not handled automagically by the compiler runtime,
they are similar [in the geometric meaning] in that: they might not be
loaded/mapped when needed, they may be nested, and storing references
to anything defined or created by them can be frought with danger.

Granted, few developers ever muck with explicit DLL management ...
most will just let the linker/runtime/loader handle it.


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

Deliberately ignoring namespaces and "static", the problem with C is
that functions all are defined globally, so any function potentially
can be called from anywhere.

Think instead how you would code it in Pascal ... or any language
having nested functions but without using closures.  Functions that
support specific computations (as opposed to generally useful) should
be defined / in scope only where they need to be callable.

Disjoint definition scopes then are exactly analogous to overlays, and
the functions defined within them can be packaged appropriately.


Note that grafting this onto a language lacking the notion of nested
functions will not be easy.


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

George

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next 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