Groups | Search | Server Info | Login | Register

Groups > comp.arch.embedded > #32456

Re: Return of the Overlays!

Show all headers | View raw

On 1/14/2026 1:39 PM, John Levine wrote:
> According to Don Y  <blockedofcourse@foo.invalid>:
>> 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).
> 
> Depends on your tools.

Yes.  I can create the overlays easily (with current tools as well as
legacy tools).

But, these typically resemble "slow bank switching" -- you can conceivably
flip back and forth between overlays at will (Borland's implementation
even allows multiple overlays to be in place concurrently, depending on
their sizes and the size of the memory segment you've previously set aside
for them to share).

So, where you allocate each identifier (text & data) becomes important
in determining performance as switching between overlays effectively
limits throughput.

In my use case, once you abandon an overlay, it is no longer accessible.
I.e., this is more similar to the CHAIN command in FORTRAN; "the past is past".

>> 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?
> 
> Still develop, no, but back in the 1980s I was one of the developers of Javelin,
> a modelling package that ran on MS-DOS. We wrote it in Wizard C, which later
> became Turbo C, in medium model so all of the static data was in one segment
> that was always resident, with the code in each module in its own segment. We
> used a third party linker that provided an overlay scheme similar to the OS/360
> one I described in "Linkers and Loaders."

Yes, but bank switching hardware is orders of magnitude more efficient than
overlays (that have to be loaded from disk) and considerably more capable than
"load once" (my case).

If you choose a bad mapping (identifiers to sections), bank switching will
still allow you to make progress through the code, albeit slower than an
"optimal" mapping/access pattern.

In my case, if you "leave" a mapped section and then try to reference the
addresses that it occupied, you SIGSEGV.  So, you have to KNOW if there are
any lingering references to ANY of the identifiers in that section before
you unmap it.

> The linker let us (well, me) assign code modules to overlays and complained if
> it saw calls that weren't strictly up or down the overlay tree. The digital
> origami involved a lot of trial and error and guessing to see what in fact
> caused overlay swapping, largely affected in our case by the way the users used
> the program. There were about six views of the model of which you could put any
> two on the screen at once, so I had to try and guess which views were likely to
> be used together so I could put them in the same overlay.

I've never had to deal with "tool complaints" as where the identifiers resided
simply affected how quickly those references could be resolved.  Switching to
another bank just looked like "slow memory"... not DREADFULLY slow memory
(because of an intervening disk access)

As I mentioned in a reply to George, there are some low hanging fruit that
you can address:

main() {
     Initialize()

     Extinctify(&Initialize)

     DoStuff()
}

My loader will drag in the resources for Initialize.  That code will be
invoked.  Then, the OS hook that permanently marks that address range as
inaccessible and discards its contents (so other parts of the system can
make use of them).

Conceptually, this is easy for a user to understand because ALL references
that Initialize() makes are encapsulated in that invocation.  And,
presumably, main() only invokes Initialize exactly once.

[Note that Initialize can invoke other sections and those won't be
affected by the "extinction event"]

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