Opensource PPC emulation for Linux x86

[Karlos]

Hi,

I'm just posting this here in case I botched the news submission ;-)

Anyhow, some feller has apparently got a working PowerPC emulation for linux x86, discussion here, called SheepShaver (:lol:).
From what I gather, it is a JIT 32-bit PPC emulation and is able to boot MacOS 8.6..

The sourcecode is available here...

I expect the mac community is about to be cleaved in two ;-)

-edit-

I wonder what the AROS x86 crowd will make of it?

[tormedhammaren]

Yes, it's by Christian Bauer - the creator of ShapeShifter and Frodo.

[Karlos]

I dint really check up fully. I guess this isnt that new news then :-)

-edit-

You sure? I keep seeing references to someone called Gwenole...

[KennyR]

All the same, I think G5 Mac owners will be safe knowing that no x86 is fast enough to emulate them for some years yet.

[Karlos]

@Kenny - Its a JIT, not an interpreter ;-)

Whilst I am sure the G5 and probably even G3 will outclass it just now, it remains to be seen what an aggressively optimised x86 implementation for the latest x86 processors would be capable of. Just look at emulated 680x0 under Amithlon for example.

In the end it comes down to price. You might not get G5 performance for several years but you might get something at a better price/preformance ratio.

[KennyR]

Karlos wrote:
Kenny - Its a JIT, not an interpreter ;-)

Even JIT withers in the face of native speeds. With the best JIT you might get 35% of the host CPU raw speed. Anyone is welcome to correct me, but I remind those reading that standard benchmark results are useless under JIT.

Besides which, PPC has all those registers which it uses a *lot*. x86 has relatively few. Therefore it's only to be expected that PPC emulation is less effective than 68k.

Now, with x86 speeds about 3GHz at present, who wants a < 1GHz PPC chip emulated? In a world of people who want 52x angle-grinder CD-ROMs just because the number is bigger (even though they are slower than 32x in most uses), I guess not many.

[Hammer]

Deleted due to double posting.

[Hammer]

Even JIT withers in the face of native speeds. With the best JIT you might get 35% of the host CPU raw speed. Anyone is welcome to correct me, but I remind those reading that standard benchmark results are useless under JIT.

What about running AOS 68K Cinema 4D R4.2 as a benchmark program?

KennyR wrote:

Karlos wrote:
Kenny - Its a JIT, not an interpreter ;-)

Besides which, PPC has all those registers which it uses a *lot*. x86 has relatively few. Therefore it's only to be expected that PPC emulation is less effective than 68k.

I recall, 68000 has 19 registers i.e. 8 of them are for general data registers, 7 general for address registers and I can't remember the rest. I also recall, 68020 have slightly more registers than the 68000.

Note that, just having (exposed) 8 general purpose registers didn't stop AMD32 processors in emulating AMD64 processor (via SimNOW). AMD64 has 16 exposed general purpose registers (AMD64 mode only).

PS; One could use Pentium IV's  hyper-treading(tricky) for playing with a total of 16 (8 + general purpose registers...

[Hammer]

In a world of people who want 52x angle-grinder CD-ROMs just because the number is bigger (even though they are slower than 32x in most uses), I guess not many.

My old LG 52X (max) speed CD-ROM is faster than my ancient Acer 36X (max) speed CD-ROM.

[bhoggett]

@KennyR

Even JIT withers in the face of native speeds. With the best JIT you might get 35% of the host CPU raw speed. Anyone is welcome to correct me, but I remind those reading that standard benchmark results are useless under JIT.

While it is true that standard benchmarks are useless under JIT, real-life application results are not. What exactly do you base that 35% on?

Besides which, PPC has all those registers which it uses a *lot*. x86 has relatively few. Therefore it's only to be expected that PPC emulation is less effective than 68k.

Until someone sees a properly optimised JIT, that's speculation. I distinctly remember people saying similar things about 68k emulation, and we all know what happened there.

Now, with x86 speeds about 3GHz at present, who wants a < 1GHz PPC chip emulated?

As a matter of fact I might. I'd like to test whether my program works under MacOS X, for instance, without going to the stupid expense of buying a Mac or a Pegasos or an AmigaOne, and lightning speed might not be a consideration.

Of course, if I'd have to pay hundreds of $$$ for the emulation, it would be worthless, but if it's open source it sure as hell suits my needs better than hardware I don't have any other use for.

[KennyR]

@Hammer and bhogget

Try playing a DVD-quality DivX with Frogger 68k, emulated. My 1.3GHz PC running UAE can't do it, my Pegasos can't do it. Yet the native version can - easily. Try other apps and games that stress the CPU. In no case have I found emulator speed to get close to native speed.

But I run a lot of apps all day using hotspot JIT (allegedly the fastest current variant), and I have a 'feel' for it. Emulating 68k on a G3/600 Pegasos is just that little bit slower than the same native PPC on my BPPC Amiga. In almost all cases the emulated code is about a third as fast as equivalent native code, on Pegasos. UAE is rather slower.

My old LG 52X (max) speed CD-ROM is faster than my ancient Acer 36X (max) speed CD-ROM.

I'm sure it is - if it gets time to spin up. 200 MB+ files on CD are great for this - but not so common, especially on Amiga. Spinning up and down reduces the overall readspeed in these cases (not to mention making an awful noise and vibrating/heating the rest of your components).

[Rodney]

It's still going to be slow isnt it? I mean, you'r not going to be able to run you'r even near what they're support to run at. That is, i assume its slow. Look at 68k emulation, thats not too bad, but thats mainly because everyone has low expectations because the 68k CPU's are very slow compared to x86 CPU but the PPC is on par basicly.

I'd be surprised if you could run MacOSX at a good speed!

[Karlos]

Whilst I am, the first to point out that from a coding model, the x86 sucks like hell, the whole register issue is a lot more complex than "it doesnt have enough registers to emulate it well"

Internally, the differences between RISC and CISC blurred years ago.

In fact, most recent x86 chips have stupid numbers of registers, existing as 'shadows' of the main register file. This is like the rename register concept in PPC.

Nobody really thought that AMD and the like get the performance they do by actually relying on a 4 register user model, did they? :lol:

As for performance, Kenny is right that 'normal' benchmarks are pretty useless way of determining JIT performance. Quite where he got 35% from is hence also dubious - one application is hardly representitive.

All I am saying is that it is the start. The whole x86 is driven by competition far more fierce than the PPC platform.

It could be that in a few years, emulation of current generation of PPC chips on whatever lunatic clockspeed x86 room heaters are out by then is faster and yet still cheaper...

[Karlos]

Rodney wrote:
It's still going to be slow isnt it? I mean, you'r not going to be able to run you'r even near what they're support to run at. That is, i assume its slow. Look at 68k emulation, thats not too bad, but thats mainly because everyone has low expectations because the 68k CPU's are very slow compared to x86 CPU but the PPC is on par basicly.

Well, thats subjective. A friends AthlonXP 2800 system runs 680x0 code about 15-20x faster than his CSMK III 68060 @ 50MHz if programs like photogenics, Cinema4D, lame, Quake1 and what not are anything to go by.

I can tell you, thats not slow, not even by PPC standards. His 680x0 emulation is certianly considerably faster than my BlizzPPC for raw number crunching.

If this PPC emulation can be optimised at least as far as that 680x0 JIT, it would doubltess outperform any 60x on that hardware.

As it goes, It's very early days and I expect the emulation is pretty slow for now.

As for its potential, who knows?

[tormedhammaren]

@Karlos:

You sure? I keep seeing references to someone called Gwenole...

Yes, Bauer still maintains this project (at least 2.2). If you extract the archive and read SheepShaver-2.2/doc/Linux/contact.html the names of the authors are listed:

SheepShaver was brought to you by:
  *  Christian Bauer (kernel, disk I/O)
  *  Marc Hellwig (graphics, sound, networking)