[LispM-Hackers] Wasting time

[Tim Moore]

On 28 Mar 2002, James A. Crippen wrote:

> Tim Moore <moore@bricoworks.com> writes:

> > address 0 it is not contiguous.  Furthermore, from some of the dumps
> > I've seen it looks like there GC related forwarding pointers in
> > there too, so we may well need to implement the incremental part of
> > the GC algorithm to get into a running state.
> 
> But aren't (I don't recall offhand) the GC forwarding pointers also
> virtual?  So if they point to VM then they don't have any relevance to
> PM.

Right, I didn't mean that this was an argument for simulating the physical
memory map, more an argument for fidelity in simulating VM.

> 
> > It would be tempting to cheat on the VM implementation, but the
> > startup code "knows" about the structure of the VM tables and
> > resizes them based on its probes of the Nubus slot address space.
> > And that leads to why a physical memory simulation seems inevitable
> > to me as well: various Lisp code knows about physical addresses.
> 
> I think that we can get around some of it since the accesses to PM are
> done through specific macroops.  These macroops can work however we
> want to implement them, ie fiddling with their arguments, doing table
> lookups for actual data, translating requests for device drivers,
> whatever.

I see a lot of %nubus-read and %nubus-write scattered throughout...  In
particular, something we'll hit early is %boot-virtual-memory, which is
the startup code I was refering to above.  This code both expects VM
tables to be already created, and then creates new VM tables that the
system expects to use.  This all involves probes of the Nubus and access
to physical memory addresses.

 > 
> > Does it do "I/O" (disk communication, for example) to known physical
> > addresses?
> 
> Yup.  But again this IO is done through particular macroops that could
> be implemented according to our own evil purposes.
> 
> > I think we want to write classes that implement the various Nubus
> > devices, including memory, and dispatch to them when decoding a
> > physical memory access.
> 
> I think this would fit very well with the above method.  The dispatch
> is done by the special macroops that know more than they should about
> their arguments.
> 
> > Anyway, is anyone else thinking along these lines or doing work on
> > the memory part of the system?
> 
> Obviously, yes.  But not being particularly informative about it.
> 
> I'm just spouting off right now, but I get the feeling that there's no
> reason why we have to build an actual simulation of the low level MM
> hardware system.  I think that we can do all of it through adroit
> manipulation behind the scenes.  We can maintain VM and do special
> traps upon accesses to known areas of the VM which are then faked by
> side effects.

Ok, I'm not sure whether you're agreeing that we need to simulate the VM
algorithms or not; I'm sensing definite resistance on simulating PM :-)
I think it will be a lot simpler and robust in the long run to do some
simulation of the hardware -- which will be localized -- rather than try
to fake it in various macroops all over the place.  The VM system seems
pretty simple as these things go; the interfaces to physical memory and
the hardware seem fairly simple as well, as the system relied on smart
controllers on the Nubus boards.

If you're worried about performance in resolving every memory address
through a complicated memory scheme, I think that short-circuiting of the
mapping for actually memory is quite doable... if that turns out to be a
problem area.

On a different subject, can anyone explain how Extended Address Space
works?

Tim