Porting MOL to Intel Linux?

[Tony Mantler]

At 3:47 AM -0600 2/10/2000, Gabriel Paubert wrote:
>On Wed, 9 Feb 2000, Tony Mantler wrote:
[...]
>> It shouldn't be terribly complicated to come up with PPC equivilant code
>> for x86 operands and set up a little virtual userlevel-only x86
>> environment. Optimizing it, however, is another thing entirely. :)
>
>Indeed, there is a small realmode x86 emulator out there which I wrote
>only to execute BIOS ROM code (otherwise the screen would never come up
>right). It is in my prepboot bootloader and a user mode version is at
>ftp://vlab1.iram.es/pub/other/em86_user.tgz.
>
>Missing features:
>- protected mode segmentation (not very complex, but maybe heavy penalty
>if you want to perform all checks)
>- FPU (hard)
>- paging, hard if you want to be fast, but applications should not
>even know that paging exists
>- debug registers, you don't even want to know that they exist...
>
>in other words it's a 486SX real mode only emulator. The current version
>is small (24kB), running at the speed of a 33MHz 386 on a 200MHz 603e.
>There are ways to make it theoretically faster but at a significant cost
>in size which could make it a cache pig (the fact that it currently runs
>entirely out of the cache even on a 603e is a big boost to performance).
>What this emulator solves is the problem of efficiently emulating the
>flags (just have a look at the code).

In theory, one could completely gut the linux kernel, prop it up in an
emulator inside an optimisticly simple virtual machine, and run all the
ia32 binaries you want in there, but that's a bit of a different design
goal than running ia32 binaries transparently (for suitably broad
definitions of the word) beside ppc binaries.

Though, come to think of it, that idea's almost worth pursuing on it's own
merit...


>> PPC PEM section 3.1 seems to indicate that the PPC chip reverses every
>> aligned double word, then mangles the ea of the operand to point to the
>> right address.
>>
>> Somehow that looks to me like it would break very painfully on any
>> structure (maybe?) or misaligned scalar (definatley) that was passed
>> between le and be code.
>
>No you don't want to run the PPC in LE mode, BE and use *brx instruction
>to access memory (and even memory image of registers in my emulator) since
>these instructions do exactly what you want when running the processor in
>BE mode.

Ah, I see. The PPC PEM documentations was a bit sparse about the
differences between the endian-reverse load and store instructions, and the
LE/BE modes. I'm assuming that the endian-reversed instructions are much
more sane than then LE mode then?


>Besides running the PPC in LE mode requires changing the setup of the host
>bridge if you ever access devices or handle this case specially (and you
>don't want to add a a check for device/memory access on every instruction
>which accesses memory, every single added check is a serious hit on
>performance).

In theory, since all the x86 code is userspace, any locally mapped IO range
could be flagged to generate an exception on access, at which point the
emulator would start sane-ifying things on an access by access basis.

Of course, avoiding the situation entirely would be a much preferable
solution. Most userspace shouldn't have to access IO, and anything that
does should be native PPC already.


>Now what happens in an SMP system if you run one processor in BE and the
>other in LE mode, I claim that this is slightly conflictual ;-)

A sanity nightmare atleast. :)


[...]
>Basically, I came to the conclusion that the capcbility to switch endian
>modes on every interrupt/task switch on PPC is a joke. You have to be
>always in the same mode.

I'm wondering if the whole LE mode on the PPC is a joke, or maybe some sort
of microsoft-pacifier to get them to port NT to PPC. (Hmm, on second
thought, perhaps that's a can of worms not worth opening)


Cheers - Tony :)


--
Tony Mantler         Renaissance Nerd Extraordinaire         eek at escape.ca
Winnipeg, Manitoba, Canada                       http://www.escape.ca/~eek


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/