[LispM-Hackers] Wasting time

[James A. Crippen]

Tim Moore <moore@bricoworks.com> writes:

> Thanks for making the source tarballs available; I'm sure I've
> wasted a lot of your bandwidth surfing through them.

I figured people would want these since the files *never* change.  At
least they won't be changing until we have the system booting and the
compiler running.

> Speaking of wasting time... I've been contemplating what needs to be
> done with respect to the memory systems of e3.  I think that we have
> no option but to write a fairly realistic simulation of the VM
> system and the Nubus/physical memory map.  All the addresses in the
> load band are virtual, and AIUI while the load band starts at
> 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.

> 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.

> 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.

I'll think about this a little and mail more to the list later this
evening.  Right now my GF is bugging me about getting dinner.

'james

-- 
James A. Crippen <james@unlambda.com> ,-./-.  Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us   |  |/  | USA, 61.20939N, -149.767W
Y = \f.(\x.f(xx)) (\x.f(xx))         |  |\  | Earth, Sol System,
Y(F) = F(Y(F))                        \_,-_/  Milky Way.