Amiga Workbench Simulator
Donat Ruel
after my first commodore c64, i was so much in love with the amiga and it took quite some time until i had my first amiga 500 in my hands. i still remember the smell of the package and the computer. the first boot up of the workbench, the mouse et cetera. a wonderful feeling. it was the computer i learned to program c on, after i had upgraded my basic from the c64 to amiga basic. i was fascinated by this computer, its graphics capabilities and the unbelievable amount of 512kb ram. after working with atzec c, upgrading to 1mb ram and having a ram disk to not always change the floppy disk all the time. i had the feeling that i needed to learn assembler.
at that time i was writing 3d routines, i wanted to design my own flight simulator. and assembler was a wonderful way of learning the aesthetics of minimality. having a table of clock cycles per command next to your computer and refining algorithms to run ever faster was a great joy.
so, here we are: the combination of the two would be a great thing: bring 68000 back into my life and have minix running on it. fortunately, people have ported minix to the 68000, so i hope that this adventure will not leave me dead in the desert (since the ports are usually for macs or atari st).
AROS is pretty stable and pretty complete too, as far as I can see.There are tons of software out of there that are waiting to beexecuted under our wonderful AmigaOS(tm) replacement, so why don't weallow them to have fun? :)
You must prevent the chipset from running too fast. You could do this by usinga timer so that the chipset stops when it doesn't need to run, but you wouldneed a very high resolution timer, just like the cia's one, and not allcomputers have got it, specially the PC's. So, once again, you'll have tosynchronize the 68k with the chipset.
By running native code inside the 68k emulator you stop the emulation. Themultitasking stops, the chipset emulation stops, ALL stop but the native code.It's not faster. Look at how picasso can slow down the whole emulation: it'scoded using such a technique you mentioned.
We could do this only once and then store the translated software in a sortof cache. We could implement performance tracking, so that the code couldget more optimized every time it's executed. We could use, in order to dothis, a modified version of the UAE JIT compiler, with the help of theauthor, of course.
Last year I spent about three months seeing how possible this was and wrote asmall program that would convert 68K instructions into a C type language(sort of intermediate between C and 68K ASM). Then wrote another progam thatwould convert my intermediate lanugage into whatever code.
The big problem was that AmigaOS executable files are in some kind of weirdstructure that I don't really know with strange headers etc... secondly thecode always assumes that it knows the hardware it's running on (with AROSthis is not true), thirdly the code generated was always poor (large andslow executing).
My solution was to forget about using a translator. Instead I started on aHeuristic Amiga simulator, which would run the code and try and figure outwhat the code was trying to do then generate code (probably C) to do the same.The Amiga hardware could be changed for OS calls, so there would be nohardware problems. I am a chemist, not a computer scientist so I found thewhole thing too hard to do and by this time my A1200 was failing so I gave up.
> [...] how do you handle the case in wich the 68k program tells to the OS> the address of a 68k routine to be executed by the OS later on?> The only viable solution that I see is the translation on load.
My solution to such a problem was to use the MMU to trap access to the Amigahardware address range (about 2meg...) and then emulate the registerselsewhere in memory (i.e. an interupt with a handler to read the psuedoregisters and then deal with the data in them correctly, maybe using codefrom UAE)
I know that JIT engines (UAE-JIT and Kaffe come to mind) use so-called"trampolines" to detect when a not-yet-translated subroutine is called.I'm sorry I don't know the details, but I'm sure the problem has beensolved already.
Endianess is a concern but Georg made a proposal how to run m68k files on alittle-endian processor and switch between emulated and native execution.Hm, maybe some analyzer (disassembler) for m68k files would also beinteresting and sufficient at the beginning to see whether this can be done.Can one for example avoid translating (= disassembling) hardcoded structures,i.e.
For example, if an 68k program would call OpenWindow. It gets back a pointerto a struct Window. If you only convert the Window Pointer to big-endian thenthe 68k emu has the correct pointer, but the stuff in the structure is stillall little-endian. So if the 68k program reads something from this structure:
In the first case, there is no need for endianess conversion and in thesecond, there is. A C++ compile can figure this out but C can't (thedeveloper has to and he better shouldn't make any mistakes). I thinkwith this technique, we have these advantages:
To switch between native and emulated execution is not a problem. It could forexample be done with an illegal m68k code in the jump tables where theemulator realizes that it has to execute i386 (or whatever) code now and hasto pass the arguments in the registers to the function.
The problem is the endianness of the m68k program and the environment it issupposed to be running in. A NewWindow structure that is hard coded into them68k program cannot be passed as is to the OpenWindow() function for example.All the data in the structure are in big-endian whereas the function expectsthem to be in little-endian. So you would have to swap all data before youpass it to the function and swap it back when it returns from theOpenWindow(). Then what is returned by the OpenWindow() function is a pointerto a Window structure where all data are in little-endian but here you mustnot swap the content since the system needs the content to be alright for itsown purposes.The endianness really is the problem and I really also believe that AROS canhave an emulator on a big-endian (!) machine like PowerPC; that would workjust fine.
I just finished an "intelligent" disassembler specialized into KickStartdisassembly. The way it works is really simple : it follows the code andwhen an opcode like JSR, BSR, (cp)Bcc or (cp)DBcc is found, the address issaved in a stack. When a JMP or BRA is found, the disassembler's PC isloaded with the new address. And, when an RTS or RTE is found, the PC isloaded with the stack.
Digitial's solution for this in their x86 emulator for Alpha CPU-s was to runthe code through a normal (step-by-step emulation) and "learning" what thecode did (i.e. converting it to Alpha code). When the code jumped to a placewhich already had been converted, the Alpha code was used directly. Maybesomething we can learn from?
An easy solution would be a 68k emulation for big-endian machines only, for100% system-friendly software which don't use any hardware features of AmigaOSbut could be sped up with a JIT plus kickstart/workbench in native format.
c80f0f1006