cross-compiler issues.

[William_Lott@AMIRANDA.SLISP.CS.CMU.EDU]

Rob,

So there are a couple of minor cross-compiler issues that have come up.
I've though of short-term work arounds, so we don't need to address them
before getting this SunOS pre-beta out, but we should start thinking about
them.

First of all, there are problems with swinging the ``vm'' package nickname
around.  Specifically, any macro definitions that use vm qualified symbols
have to be re-loaded, because the vm binding is resolved at load time.
Luckily, we can load multiple macro definitions by using different
info-envs, but not everything can be that simply addressed.  For example,
my alien expands have things like:

	`(sap-ref-32 ,sap (/ ,offset vm:byte-bits)) 

in them.  And given the way I've written the alien stuff, we can't load
different expansions.

The array creation stuff in array-tran is another bag of worms.  There are
references to vm:simple-mumble-array-type, etc. which (currently) don't get
re-loaded.  I guess this one is easy to address.

And type-predicates.  Typetran maintains type->predicate and
predicate->type mappings in a regular hash-table and alist.  Therefore,
only one set of mappings per lisp, not backend.  But this one isn't a
problem in practice, because we have the same set of predicates on all
systems (and none of the symbols are in the vm package).

So there are basically two problems: some compiler information isn't
maintained in the globaldb, and the ``vm:'' package qualifier gets resolved
at loadtime.

Both these problems are solvable.  We just move more info into the globaldb
or backend struct, and reload everything that uses the vm package.  While
using the globaldb or backend struct for more stuff might be a good idea in
and of itself, I don't like the idea of re-loading lots of stuff.  One
indirection (the symbol name) should be enough.

If we left the VM package the same and just relied on the globaldb to
resolve conflicts, then we could easily support shadowing defconstants and
defmacros, but defuns would still cause us problems, because they map
through the symbol-function slot.

I guess we could have a VM package that exported the interface that was
common across the different backends, but let defuns and other runtime shit
continue to live in the PMAX or SPARC, etc. packages.  I'm not sure what
would be the best.

-William