EM86 port for LinuxPPC?

EM86 port for LinuxPPC?

[Joseph Palani Garcia]

Some may have noticed the EM86 x86 "emulator" for alpha/linux to run
x86/linux binaries.  I recently added the define to my kernel compile and
it compiled the binary support (the em86 program gets help from the
kernel, so theres a kernel define in the alpha kernel config).  Anyway,
I downloaded all the source from digital's site, and tried compiling it.
It all compiled fine except for one thing, the thing i am doubious about.
a source file that is only about 25 lines of assembly.  What i think it
does is reroute the syscalls to the friend in the kernel.  It seems to me
that because of this, it may be bound to the alpha architecure.  Is there
a way to port this to ppc?  or is there just too many dissimilarities
between alpha and ppc archs?  ( i haven't tried doing it yet because i
don't know if its worth the time in learning alpha and ppc assm/arch just
to get x86/linux bins to run... or im just lazy)

Thanks.

--

Joseph Garcia
Madison, WI
jpgarcia@execpc.com


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: EM86 port for LinuxPPC?

[Brad Boyer]

> Some may have noticed the EM86 x86 "emulator" for alpha/linux to run
> x86/linux binaries.  I recently added the define to my kernel compile and
> it compiled the binary support (the em86 program gets help from the
> kernel, so theres a kernel define in the alpha kernel config).  Anyway,
> I downloaded all the source from digital's site, and tried compiling it.
> It all compiled fine except for one thing, the thing i am doubious about.
> a source file that is only about 25 lines of assembly.  What i think it
> does is reroute the syscalls to the friend in the kernel.  It seems to me
> that because of this, it may be bound to the alpha architecure.  Is there
> a way to port this to ppc?  or is there just too many dissimilarities
> between alpha and ppc archs?  ( i haven't tried doing it yet because i
> don't know if its worth the time in learning alpha and ppc assm/arch just
> to get x86/linux bins to run... or im just lazy)

I looked into this earlier, and even started to work on it, but I went
on to something else before I got finished.  The major problems as I
saw them were that all the code for EM86 assumes a 64 bit
little-endian architecture, and it would be annoying to track down all
those assumptions and correct them.  That is doable, but time
consuming.  The other major headache is that the actual CPU emulation
used is the proprietary FX32 library from DEC.  We would have to write
our own x86 emulation library to replace it.  This isn't so much of a
problem, because there is already a basic x86 emulator in one of the
bootloaders, to be able to run BIOS code from PCI cards with x86 BIOS
chips on them.  I started looking at it, but then I went on to
something that was more interesting, and I felt was more useful.  I'd
be glad to share more detailed thoughts on this if anyone wants.

	Brad Boyer
	flar@cegt201.bradley.edu

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

[patch] mol quit-at-shutdown

[Brad Midgley]

with this patch, mol quits when macos tries to pull down the power so the
macos shutdown action cleanly exits the emulator.

it appears all the mol cleanup is done in an atexit routine so i figured
this would be safe. my only concern is that it looks like macos does a
couple of scsi operations AFTER telling the cuda to power down. maybe i
should set an alarm and have the alarm kill the emulator instead...?

i would like to make the debugger interface optional via a command-line
interface to mol next...

--- ../mol/drivers/cuda.c       Fri May 21 12:47:58 1999
+++ ./drivers/cuda.c    Thu Jun 10 15:26:21 1999
@@ -332,7 +332,9 @@
                printm("CUDA: rest system\n");
                break;
        case CUDA_MS_RESET:
+               break;
        case CUDA_POWERDOWN:
+               exit(0);
        case CUDA_POWERUP_TIME:
                break;
        case CUDA_AUTOPOLL: /* input_len/output_len : 1/0 */


Brad
brad@pht.com | http://www.pht.com/~brad/



[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: EM86 port for LinuxPPC?

[Geert Uytterhoeven]

On Thu, 10 Jun 1999, Joseph Palani Garcia wrote:
> Some may have noticed the EM86 x86 "emulator" for alpha/linux to run
> x86/linux binaries.  I recently added the define to my kernel compile and

Gabriel Pubert wrote an em86 for PPC that for initializing video boards using
the ia32 code in the video BIOS.

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: [patch] mol quit-at-shutdown

[Benjamin Herrenschmidt]

On Thu, Jun 10, 1999, Brad Midgley <brad@turbolinux.com> wrote:

>it appears all the mol cleanup is done in an atexit routine so i figured
>this would be safe. my only concern is that it looks like macos does a
>couple of scsi operations AFTER telling the cuda to power down. maybe i
>should set an alarm and have the alarm kill the emulator instead...?

Those are probably the cache flush commands. They can probably be safely
ignored within mol. for safety, you may want to add a delay before the
actual shutdown of the emulator, I think 1s should be fine.

-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>




[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: EM86 port for LinuxPPC?

[Andreas Bogk]

Brad Boyer <flar@cegt201.bradley.edu> writes:

> our own x86 emulation library to replace it.  This isn't so much of a
> problem, because there is already a basic x86 emulator in one of the
> bootloaders, to be able to run BIOS code from PCI cards with x86 BIOS
> chips on them.  I started looking at it, but then I went on to

And then there is bochs, which is a complete PC emulator, and which
certainly could be modularized:

http://www.bochs.org

It reaches the speed of a 2 MHz 486 on my 300 MHz G3, so it's not
exactly a viable option for running x86 binaries on PPC.

Andreas

-- 
Reality is two's complement. See:
ftp://ftp.netcom.com/pub/hb/hbaker/hakmem/hacks.html#item154

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: EM86 port for LinuxPPC?

[Brad Boyer]

> And then there is bochs, which is a complete PC emulator, and which
> certainly could be modularized:
> 
> http://www.bochs.org
> 
> It reaches the speed of a 2 MHz 486 on my 300 MHz G3, so it's not
> exactly a viable option for running x86 binaries on PPC.

In addition to being slow, it's also not free.  In any sense of the
word.  Bochs is shareware last I checked, so you're supposed to pay
for it if you use it.  The source code is available, but the license
didn't even resemble open source from what I could tell.  We might be
able to get a few hints from it, but we'd be in trouble if we used
anything directly...

		Brad Boyer
		flar@cegt201.bradley.edu

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: EM86 port for LinuxPPC?

[Gabriel Paubert]

On 11 Jun 1999, Andreas Bogk wrote:

> And then there is bochs, which is a complete PC emulator, and which
> certainly could be modularized:
> 
> http://www.bochs.org
> 
> It reaches the speed of a 2 MHz 486 on my 300 MHz G3, so it's not
> exactly a viable option for running x86 binaries on PPC.

Indeed it's slow, but I looked once at the code of Bochs: performing
explictly the virtual to physical memory mapping by emulatingthe TLB in
software is not exactly cheap. That's an area where using hardware
resources with a hook in the kernel might speed up significantly. There
are other issues too (slow endianness conversion, ...)

Of course I did not have these problems with my emulator because it only
emulates a real mode 486SX for now, which runs at the speed of a 25 to 33
MHz 386DX on a 200Mhz PPC603e. 

I have some ideas to implement protected mode and to speed it up by maybe
30%, but abolutely no incentive to do it.  

	Regards,
	Gabriel.


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]