[LispM-Hackers] load band help

[Dave Richards]

Good sleuthing here.  I was I could find somewhere in the source where this
format is made clear.  The memory-management directory has code which
updates the DPMT, it actually implements the "save new band" code.  I have
not made progress in deriving the exact structure though.  I missed those
two symbols.  I did read the same section on areas, but assumed that the
band had metadata in front, like every other reason file in the world. :)  I
have been puzzling over the load band for two days now.  I decided to
re-check the archives to see if I had missed anything (and I had).

I'd really like to put this load band format to bed for good.  The DPMT is
well documented.  It's what preceeds the DPMT that bugs me.

	Dave

> -----Original Message-----
> From: lispm-hackers-admin@lists.unlambda.com
> [mailto:lispm-hackers-admin@lists.unlambda.com]On Behalf Of Nyef
> Sent: Sunday, January 13, 2002 7:23 PM
> To: Carl Shapiro
> Cc: lispm-hackers@lists.unlambda.com
> Subject: Re: [LispM-Hackers] load band help
>
>
> 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
>
>
> http://lists.unlambda.com/mailman/listinfo/lispm-hackers