Last update: 30.12.2006
in Spanish, in Hungarian
Table of contents
Project Petunia is a Motorola 680x0 processor emulation with dynamic recompilation for PowerPC based Amigas.
Dynamic recompilation (or also called just-in-time compilation or simply JIT compilation) is a technique of translation of the emulated processor machine code to an executer processor machine code on-the-fly.
This technique is a common method nowadays, usually used in JAVA applications, and it is also applied in several emulators with success.
Petunia is officially part of AmigaOS4.
The target of the emulation is high compatibility with Motorola 68040, without MMU support.
What is it capable of (V52.2)?
The actual version is already running in close cooperation with the interpretive emulation in AmigaOS4.0.Emulated opcodes:
- all integer opcodes of the 68040, except MMU- and cache-related opcodes,
- all of the 68881/882/68040 FPU opcodes, except: FSAVE. (Including software-only supported 68040 opcodes.)
all addressing modes which is supported in 68020 and up,
byte, word, longword, single, double, extended data for the FPU.
Flag emulation: all flags.
At compile time a low level flag data flow analysis and branch control allows on-the-fly optimizations on compiled code.
Virtual context switches implemented in the PowerPC native code or the interpretive emulation (fallback), it is called automatically when needed.
The emulation of executables can be controlled via a so called black list, if an application was black listed then the emulation of that executable falls back to the interpretive emulator.
What programs are not working for now? Those who
- Registers: SFC, DFC
- Opcodes: CALLM, RTM, CINV, CPUSH, PFLUSH, PFLUSHA, PTEST
- contain some kind of unemulated opcode (see Emulated features above);
- are badly written, causing memory hits, or self-modifying in an illegal way.
- special case optimizations on the translated code to gain even more speed.
Go, get AmigaOS4.0 Final and see it for yourself.
Frequently Asked Questions
After a long period of checking forums, chat boards and answering e-mails I decided to add a FAQ part into the project page. I hope I can clean up the more important questions that you may have.
If something is not clear enough feel free to write me a mail.
DO NOT listen to the trolls/morons on the forums/mailing lists, many of them state that he/she is knowing how things are working, but they don't know. (Especially not the internal working of the emulators and the AmigaOS4 system.) If in doubt ask me.
Please don't wait for my answer on any particular forum, I don't have enough time to browse trough them always.
If you have a question then ask me.
When will the emulation be ready?
It is done.
Why is the version number so high? I remember it was under 1.0/ it was 50.x when I last checked this page. What happened?
A version number really says nothing, it is only a fiction of the software author. AmigaOS4 components have the normal version number actually starting with V52, therefore Petunia has this version number too as an AmigaOS4 component.
What kind of processor will be emulated?
Motorola 68040 with FPU, but without Memory Management Unit (MMU).
68040 only? And what happens with the program which is optimized for 68060?
Don't worry, that which works on 060 also works nicely on 040.
But AmigaOS4 reports only a 68020+FPU. I just checked in my prerelease! So, what is all about?
That is only a technical question, it is rather safe to report a lower CPU to the applications, but that has nothing to do with the capabilities of either integrated emulator. Both are working in 68040 mode, which is compatible with any 68020 program.
(This last sentence is not completely true: programs which are relying on the FPU stack frame could fail, but that is very-very rare fortunately, mostly used for hacking something into the system. FPU stack frames are not emulated properly for now.)
What happens with the "software supported" 68881/882 FPU opcodes? Do they need some kind of software emulation like Oxypatcher?
No, that would be nonsense. I implemented all the 68881/882 FPU opcodes like it would be supported by the processor "natively". So there is no need for any patching, like 68040.library or Oxypatcher.
How fast will the emulation be in AmigaOS4?
The emulation is working at least an M68060/50Mhz level on a PPC604/180. Faster processors will gain more speed, of course.
Some opcodes and operations need more effort from the emulator to keep it compatible, the others are easier to implement, therefore the actual speed is highly depending on the emulated 680x0 code.
Will my favorite AGA/ECS game/demo work?
To tell you the truth: I wouldn't think so. My work is about a processor-only emulation and not about the full legacy support. The chipset dependencies of an AGA program cannot be solved simply. (It would be a really tough work.)
There is only one chance to get most of the old stuff working: by using UAE. You can use a native version of UAE for AmigaOS4 and it is working well.
My opinion is 90-95% of the system friendly 680x0 programs will work properly under Petunia anyway, but hopefully you will see it for yourself.
Do you plan any support for UAE?
I don't know yet. There is a possibility of reaching the emulation from the "outside", so theoretically UAE could make use of Petunia's engine, if somebody does a special version. I don't intend to do it, but I would help gladly help to anybody with this work.
I heard that Petunia is a derivation of UAE-JIT/other emulator. Is it true?
Petunia has nothing to do with JIT version of neither the Intel nor the PowerPC based UAE, my emulator is working in a very different way. It is completely my work, based on my ideas. (To tell you the truth: I don't even know exactly how the JIT translation is working in UAE, I haven't checked yet.)
How does the emulation work?
There are three approaches for emulation:
- a full machine emulation with emulation-traps for a very few native code snippets, UAE is working with this method,
- a virtual machine starts every time, when an emulated program started, every resource are virtualized (so called: Amiga-in-the-box or sandbox-emulator), JAVA Virtual Machine and MacOS X works like this,
- a task based emulation: each emulated task has its own emulation process independently from the others, with escaping trough the so called emulation-traps at each system calls to the native code.
The emulation in AmigaOS4 works roughly like this method, except that there is an MMU-based 68k code identification mechanism used in some cases. (Not at normal library calls.)
Why is it good for us? There is no need for virtualization of resources, no delay until building a complex sandbox-mechanism, each task has it's own interpretation/translation state, no interferences. The rest of the system can work in full speed, because it is 99% native PowerPC code, and every task scheduled individually. (Keeping the usual Amiga-feeling in feedback and operation.)
I read on a forum that Petunia emulates only the main executable of the applications and not the libraries/devices/plugins. Is it true?
No, not anymore. Long ago I planned to implement Petunia on this way, but we had to face that this implementation would cause problems and slowdowns for way too many applications. Therefore we changed the internals and now every 680x0 code will be emulated via Petunia which is loaded via DOS. (DOS.library/LoadSeg() function, to be exact.)
The only exception is when an executable explicitly banned from dynamic recompilation. In this case that executable will be emulated via the interpretive emulator as a fallback.
I heard that Petunia is deciding about translation of an application by examining a black list. What's this all about?
The actual version of Petunia is translating only those executables which are not banned by the black list. The default behavior is dynamic translating of any 68k code, which was loaded by DOS, but you can add any executable or library to the black list with the Compatibility preferences program thus avoiding the dynamic translation. Normally you don't have to do this.
Why are there two different emulators (interpretive and dynamic recompiler) included in the system?
In some special situations dynamic recompiler cannot be applied. For example if there was not enough memory for the translated code chunks. A few applications are not compatible with it, those are banned for dynamic recompilation. All in all: in these special cases the interpretive emulator steps in as a fallback. Luckily not very often. Also you can remove the dynamic recompiler to win some more free memory, in this case only the interpretive emulator will do the job.
Will Petunia support AltiVec in PowerPC G4/G5?
I see no real need of AltiVec in the emulation, because it does not need any periodic computation parts, except some runtime optimization in the translation and memory copy. I will check whether any SIMD opcode could be used at a later stage.
What about the upcoming PowerPC processors?
PowerPC platform is a well planned superscalar family with the possibility of easy change to 64bit implementation from 32bit one. While the future Amigas have 32bit PowerPCs as a main processor Petunia will work without any issues.
The change to 64bit PowerPC processors requires a bit rework of some parts, but it is not a huge problem.
Changing to other type of processor which is not PowerPC machine code compatible is pointless and almost impossible, because all the emulation code were made of PowerPC assembly and tied closely to this architecture.
What about symetric multiprocessor support?
Not an issue at all. Because of task-based emulation form each task has its own translation stage. As long as the kernel and the scheduler solve the sharing of free processor time for each task or thread, Petunia will gain full speed from symmetric multiprocessor environment. (A full machine emulation and sometimes a virtual machine cannot gain more speed from symmetric multiprocessors, so task-based emulation is a better approach this time too. See above: How does the emulation work.)
Are you thinking about implementing Petunia on Intel (compatible) processors?
No, I don't code on Intel if it can be avoided somehow. Thanks for asking... ;)
What is your opinion about AmigaOS4?
It is nice in both design and implementation. Good work guys! Now I can contribute some more speed with Petunia... :)
Remember the change from AOS1.3 to AOS2.0? AmigaOS4 is much bigger step forward.
Do you plan to share your work with the MorphOS guys?
No. MOS has its own way, which is different from what I want. They have their own solution anyway.
Not at this time.
I would like to thank to the following people for helping me in several ways (direct or indirect) in realizing this project (in no particular order):
Thomas Frieden, Hans-Jörg Frieden, Colin Wenzel, Michael Sinz, Frank Wille, Steffen Häuser, Sam Jordan, Thomas Richter, Jochen Becher, Stephen Fellner, Csaba Simon, Ben Hermans, Timothy De Groote, Sven Ottemann, Ben Yoris, Konrad Bielski, Jörg Strohmayer, Adam Kowalczyk, Martin McKenzie, Bill Borsari, Nicolas Mendoza, Philippe "Elwood" Ferrucci, Viktor Varga, Péter "Jam" Markovits, Tamás Baldauf, Emeric/SpaceHawks, LouiSe, Artlace, Tibor Szakács, László "Ph03n1x" Török, Attila Bácskai, Róbert Márk Horváth, Blackie, Sau, Charlie/inQ, Víctor Gutiérrez, Andreas Loong, Ian Greenway
Csaba "UnReal" Kémeri for the project logo.
Check out my contact page, click here!
Back to main page