Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!decvax!ucbvax!ji.Berkeley.EDU!shs
From: shs@ji.Berkeley.EDU (Steve Schoettler)
Newsgroups: comp.sys.amiga
Subject: Re: Use of Resident
Message-ID: <21466@ucbvax.BERKELEY.EDU>
Date: Mon, 26-Oct-87 20:23:02 EST
Article-I.D.: ucbvax.21466
Posted: Mon Oct 26 20:23:02 1987
Date-Received: Thu, 29-Oct-87 02:00:36 EST
References: <4086@garfield.UUCP> <21428@ucbvax.BERKELEY.EDU>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: shs@ji.Berkeley.EDU.UUCP (Steve Schoettler)
Organization: University of California, Berkeley
Lines: 60
Keywords: resident
Summary: how about a smart reloader?

In article <21428@ucbvax.BERKELEY.EDU> bryce@hoser.berkeley.edu.UUCP (Bryce Nesbitt) writes:
>
>REENTRANT  This means you can run the same program twice in the same memory
>image.  We'll assume a single progcessor environment :-).

  You don't have to.

  The requirements for multiple processors running the same code image
are the same as those for multiple tasks running the same code (in terms of
code and data spaces).
  Now, if you have to synchronize them, that's another story.

>
> A recoverable resident is a hot idea...
>
>If the program is NOT reusable the new resident was to treat itself as
>a RAM disk, it would "reload" the program for each invocation.
>

  I had an idea about a year ago but forgot about it until now.

  What about sorting an exacutable file's hunks on the disk so that the data
hunks come first?  Then rewrite LoadSeg() to first look and see if the
program is "resident" and if so, only load in the new data hunks.
  This could result in much faster loading for programs already running, and
more efficient memory usage.
  Programs could modify variables (including globals) however they wanted
because they would all have their own data space.
  You also have to rewrite UnloadSeg to know about this.

  Since each task has a segment list, it would have to be organized as follows,
with the data segments at the head of the list and the code segments at the
tail:

task1->seglist-> first   second           last
                 data -> data   -> ... -> data   -
                 block   block            block   \
                                                   \
                                                    \   first           last
                                                    /-> code  -> ... -> code
                                                   /    block           block
task2->seglist-> first   second           last    /
                 data -> data   -> ... -> data   -
                 block   block            block  


  Reorganization like this would make a fork() routine trivial: :-}
      copy all data blocks,
      create a task and build a its segment list as shown above,
      copy the stack and registers,
      do a get_aX() (whatever it takes to point to the base of data space)
      and return from fork() appropriately.

  Now that I remember, I started to write something to do this, but when you
start getting into the internals of LoadSeg and the DOS loaders, it gets ugly.

  Is this plausible?  Anyone else want to pick up the ball?

  Steve Schoettler
  ...ucbvax!ji!shs