Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!sun-barr!texsun!pitstop!sundc!seismo!uunet!mcvax!hp4nl!phigate!philmds!leo
From: leo@philmds.UUCP (Leo de Wit)
Newsgroups: comp.sys.atari.st
Subject: Re: Preloading revised
Message-ID: <1029@philmds.UUCP>
Date: 14 May 89 20:23:47 GMT
References: <1028@philmds.UUCP> <1494@atari.UUCP>
Reply-To: leo@philmds.UUCP (Leo de Wit)
Organization: Philips I&E DTS Eindhoven
Lines: 52

In article <1494@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes:
     [about the preload example]
|Except for one thing: some programs expect their basepage to be $100
|bytes below their text base.  In fact, virtually all programs make that
|assumption to one extent to another, but most of them use it to
|determine how to Mshrink, and being off by $100 bytes won't matter. 

In this case they will just use for the Mshrink the address of the old
basepage that was created with Pexec(3) (load/nogo) in front of the
text segment.  I think this probably won't present a problem (at worst
the Mshrink fails, if the parent process already has set the child's
space to a smaller size).

|And another thing: a program which assumes any initial state for a
|variable in the data or BSS segment will lose, because the second time
|you start it the variable will have a leftover value from the previous
|execution.  You can fix this problem by saving a copy of the initial
|data segment and copying it into the process before starting it again,
|and clearing the BSS (just the declared part; you don't usually have to
|clear the whole heap).  If a program modifies its text segment, this'll
|lose, but hell, at that point it'll be quicker just to load it off a
|RAMdisk.

Alas, some compilers place the data segment in the text segment, when
producing 'large model' code. If a data segment exceeds 64K, it can't
be addressed (in a simple way) using 'address register indirect with
displacement' mode a la 40(a4). So they produce absolute code (for 
Lattice this is even the default), and to make sure the data segment
is relocated correctly (it could contain pointers, for instance) it
is added to the text segment.
What I found to be a good strategy for programs to be preloaded if you
plan to make use of that mechanism (but your mileage may vary):
Explicitly initialize all static and global variables that are being
written to and must have an initial value (most of the time there
aren't that many). If you're programming in C, you could call at
the top of main() for each module that goes in the link a function
that does the initialization of the globals and statics of that file.

About the RAMdisk: an advantage of preloading is that you need only
one copy of the program in memory (with 1M of memory this can still
be a big win). Another advantage is that relocation is not needed
anymore (only Pexec(0) and Pexec(3) relocate). Yet another example
is that you have more control over the image before you run it (you
could perhaps even set up a real argv on the user's stack); even 
things like pipes and multiprocessing come to mind (becoming lyrical
here 8-).

|Very cool idea.  I might try to add some builtins to Gulam this way.

Thanks for the compliment!

    Leo.