[LispM-Hackers] load band help

[Nyef]

On Sun, 13 Jan 2002, Carl Shapiro wrote:

> I have been trying to figure out the format of a load band, and have
> been left terribly confused by some code in e3 which I have included
> below:
>
> (see band.cc, line 223)
>
>   e3WordAddr e3Band::load(e3MemMap *m)
>   {
>   #ifdef NOTDEF
>     dumpRegions();
>   #endif
>
>     e3Word dpmt = readWord(NUM_REGIONS + 9);
>     e3u32  origin_address = dpmt.getPointer();
>
>     ...
>
> NUM_REGIONS is defined to be 2048.  I would very much like to know
> what the corresponding constant on the Explorer is.  I suspect it may
> be SI:SIZE-OF-REGION-ARRAYS, but I am short on compelling evidence.
> The 9 that NUM_REGIONS is summed with confuses me even more.  I have
> positively no idea why we seek that many words father into the band.

Well, (2048 + 9) << 2 is 0x2024. At that position in the load file we
find (output from a program knocked together for this purpose):

00002024: 0a003c00 '.<..'  CDR-NORMAL  DTP-Fix

Looking further in band.cc, we find it looking for DPMT entries at the
address contained in that FIXNUMs pointer field, which is file offset
0xf000, which looks suspiciously like a collection of DPMT entries.

Looking at the DPMT entries, we find the first three clusters worth to be
unmapped, and the next cluster has a disk offset of 3, which implies to a
first approximation that the first three clusters of the load band aren't
under control of the virtual memory.

SSDN2, page 9-6, lists a number of standard areas, and says that the first
one is wired to virtual address zero, and contains the Symbols T and NIL.
The first 256 words of the load band contain two symbols at 5 words each
followed by 246 words of DTP-Null.

Noting the fixed addresses for both the Resident Symbol Area (on page 9-6)
and the System Communications Area (on page 9-9, given in octal but works
out to 0x200), the fact that the Region Origin Area is fifth on the list
of standard areas, and the Disk Page Map Area is tenth, we look at the
load band starting at 0x2000, and notice a definate correlation between
the data values there and the known starting positions for the three
regions we know, and we come to the conclusion that we have found the
Region Origin Area.

It would appear, therefore, that the system simply reads a certain amount
of the load band into the start of the virtual address space, and simply
pages everything else in on an as-needed basis (this is corroborated by
SSDN2, page 6-10).

We also conclude that the reference to NUM_REGIONS in the code quoted
above is wrong, since the position of the region origin table in the load
band is only coincidentally the same as the maximum number of regions in
the system. The first word of the System Communications Area (which is
given to be at 01000) is the VA of the Area Origin Area, which also
appears to be the Region Origin Area (?). (I suspect an SSDN2 bug here,
since there is no Area Origin Area listed among the standard areas, and
they are in the same place in the load band.)

> Have I missed a section of the SSDN where these aspects of load band
> are discussed?

I doubt it. I've read most of SSDN2, and it doesn't actually say much
about the format of the load band, save how it relates to the virtual
memory system (see section 6), which is to say that it's mostly read-only
swap space for the virtual memory system (similar to a demand-paged
executable on UNIX systems).

Now I have a question for anyone who can answer it:

Is the beginning of the load band loaded before the virtual memory system
has been initialized (memory-management/vm-boot.lisp), or is the cold-boot
code stored in the microload band?

---------------------------
All programming can be viewed as an exercise.
---------------------------
Alastair Bridgewater
e-mail: nyef@softhome.net