Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!uwmcsd1!leah!itsgw!steinmetz!uunet!portal!cup.portal.com!bcase
From: bcase@cup.portal.com
Newsgroups: comp.arch
Subject: Re: Software Distribution
Message-ID: <8754@cup.portal.com>
Date: 4 Sep 88 03:29:47 GMT
References: <1988Aug23.180420.28483@utzoo.uucp> <958@esunix.UUCP> <1988Aug2
Organization: The Portal System (TM)
Lines: 56
XPortal-User-Id: 1.1001.5156

Rob Warnock asks the soon-to-be 64 $ question:

|(Hmmm... how hard is it for each of the current RISC CPUs to emulate each
|of the others?)

Ah!  Something to which I can speak informedly.  I assume that Rob is really
asking about binary recompilation, but the problems are similar for straight
(not g... oh never mind) emulation.  By far, the biggest problems in
architectural emulation are:

1) Dealing with byte-sex differences (big vs. little endian, that is),
2) Dealing with alignment restrictions (everything aligned to natural
   boundaries?),
3) Dealing with indirect branches.

Number 2 is seldom a problem when you are talking about emulating a RISC
on a RISC since RISC architectures better reflect the realities of memory
system design and call for each data type to be aligned on its natural
boundary.  However, when emulating a machine that allows 32-bit words to
be aligned on byte boundaries on a machine that doesn't, say a 68020 on an
88000, a significant performance hit is taken unless exhaustive analysis
is done.  Even with exhaustive analysis, it might still be necessary to
allow for the worst case (hmmm, this pointer is being passed and then
dereferenced and I have no information about its origin, sh*t, I'll have
to assume that it could be aligned any ol' which way.).

Then there are indirect branches.  What are the targets?  If you can't
tell, say by locating and decoding an associated switch branch address
table or something, then the only 100% safe, bullet-proof thing to do is
to assume that any instruction is a potential target of this branch.  With
that assumption forced upon your binary recompiler, many inter-instruction
optimizations are prohibited.  Another way of stating this problem:  you
can't tell where the basic blocks are.

The indirect branch problem is not an architectural one, but one of loss
of information:  the basic block boundaries that were marked by labels in
the intemediate or assembly form of the program are no longer explicitly
marked.  Note that the C language allows a case within a switch to fall
through to its lexical successor!!!  Thus, for an intermediate language
or virtual machine architecture to be usefully portable, this information
must not be compiled or linked away.

As tough as this problem is, things like alignment restrictions and single-
sized instructions, RISC characterists for the most part, make this problem
easier to handle.  There are a couple of tricks, not necessary without
tradeoffs, that can be played.  But I'm not telling....

Other things like lots of registers help, especially if the machine being
emulated has a condition code definition different from the host machine
(virtually guaranteed; at least the SPARC has a bit that determines when
the condition codes are modified, and, when they are, they are modified
in the same way by all instructions).

Even under the best circumstances, you don't get something for nothing;
emulation or recompilation isn't a panacea.  If it were, we'd all just
design our favorite machine and then buy Zycad simulators to "run" them!