AROS 68k EMU

[Crumb]

Wouldn't it be possible on systems with the same endianess of the 68k to run an integrated 68k emulator like in OS4 or MOS?

[Crumb]

And is the 68k version still being developed?

[Crumb]

On x86 wouldn't be possible to force 680x0 programs to make function calls inverting the words and longwords?

Couldn't you force your emu to work always in little-endian mode even if the emu was slowed down a lot and the compatibility decreased?

or...

If you can differenciate 68k emulated tasks and native tasks you may catch any access outside the 68k program memory space with the MMU and force to reverse all the words and double words.

If the emu reads or writes to a zone outside of the 68k task memory zone the MMU would trap the access and reverse the addresses. The 68k programs should be aligned in memory to convert correctly the addresses.

The mallocs and memory functions that reserve/free memory called from the 68k program would run in a separated memory zone... let's say you reserve 256MB of the virtual addressing zone for the emu. You launch your program, the scheduler detects that it's a 68k program so it allocates it in the 68k area. If the 68k program does a malloc() (or any other memory oriented function) the memory reserved will be reserved in the 256MB area, so access to memory inside the emulation zone won't be a problem. The calls to OS functions that use long words or words as arguments will reverse the order of these structures. The structs returned by OS functions to the emu will be inverted again.

I think that the OS4 68k emulation approach would be perfect for AROS (with the addition of some word and longword byteorder inversion).

[Crumb]

@Matt:
"The Best solution is to have a *special* version of AROS 68k running in an Emuator. This *special* version of AROS would not implement many functions but instead pass most over to the Native AROS x86 running the machine. This would make the 68k program appear to be running nativly with the added bonus of Chipset emulation!!! "

That's not a bad idea for x86, but on PPC and big-endian cpus as you don't have endianess problems it may be integrated as in OS4 or MOS more easily. The downside of using UAE with a "native" AROS ROM that calls OS functions is that it probably won't be as fast as an integrated emu. The advantage of being able to use hardware hitting software is a big bonus anyway...

@Fabio:
"but since programs are free to poke around in memory, there's no way you can make both native and emulated program work seamlessy together AND let them share memory. "

Well, if you mark a zone with the MMU to use it with 68k programs and other for native software you could share memory because you could know where you have to reverse words and longwords and were you haven't.

I'm not saying that it's easy but I think that it's possible. If you can notice if a program is writing on an area where you have to invert the bytes and in other were you don't and everything is aligned... it may be possible wouldn't it?

-edit:-
[offtopic] Fabio... the reaction stuff continues without linking correctly, should I use fd2pragma?

As you have done the gcc port to AROS do you know how easy is to add various targets to the same gcc "distro"? I'd like to have one 3.x 68k gcc that created code for MorphOS, OS4, OS3.x, AROS and Amithlon changing only a flag at compile time.

I would add one thing more:
If you use an integrated emu you won't need to wait until AROS is finished and you won't have to make modifications to the emu.

If you choose the UAE with "native" rom approach you will need to have a complete replacement of rom3.1 and if you change a function in AROS you will need to change it inside the emulation too and maintenance of it will take a lot of time every time something is changed.

[Crumb]

@bloodline:
"You seem concerned about performance penatys from the emulator option, but I assue you, 68k software will run much faster than any real Amiga (as it will ahve the UAE JIT) and any 68K->x86 AROS overhead would be not much greater than a byte swapping + function call...."

In amithlon native software reverses the bytes of the word and achieves a 75% of performance. We would have to add the overhead of the 68k emu, but UAE would be hardly faster.

And you are forgetting than on big-endian systems an integrated 68k emu would be FAR faster than the approach taken for the x86 port. It would be as fast as in MOS or OS4.

[Crumb]

The difficulty I see is that this approach would require that AROS was nearly finished (I mean, that it was 100% compatible with 3.1)

I guess that finishing the Amiga 68k port would help a little... once it's done it would be a matter of changing the "rom" 68k functions with functions that called native ones.

[Crumb]

BTW, what do you think about the idea of creating ONE distro that generated code for all amiga-like OSes hosted in OS3.x (firstly, then it would be ported to AROS, MOS, OS4, Amithlon, MacOS, Linux, windows...)?

Most of Amiga developers won't have linux or aros installed on their systems so there are more chances of seeing AROS soft appear.

In addition to that stupid wars would end because developers will be able to compile binaries for all targets changing only one flag.

[Crumb]

@Matt:
"it just that the only persopn with the time and experience to do it has a broken Network card (ZorroII) in his Amiga 3000 so he can't do much at the moment (how to get 100megs of sources to the A3K?)."

mmm do you know what a CD is? ;-) you burn a cd on your pc with the sources, put it in the cd of your A3k and copy the sources to your hd ;-)

Sorry, I only have a cbm 286 bridgeboard and it takes a little time to use it with an ISA NE2000 card and requires a harddisk controller without dma.


BTW: with your idea of making using native calls from UAE etc... how would you mix AROS native and 68k libraries and devices? It sounds as it would be much more difficult than using an integrated emu.

[Crumb]

@Bloodline:

"Look up openamiga.org :-)

That is the place to start such an idea :-)"

added:
http://openamiga.org/forum/viewtopic.php?t=10

[Crumb]

I think I tried it with a 133 pentium loading from disk. I didn't try the CD version...
floppies are very slow...

[Crumb]

@Matt:

How do you install AROS?
The floppy disks of sourceforge or your web can't boot, they complain about lack of execute, copy and other commands...

The CD includes some kind of installation? I couldn't find it... a friend of mine wanted to install it on a 486 laptop but he couldn't find how to install it.

Oh do you plan to add swap memory soon?

[Crumb]

"we have to finalise a design for an mmu.library (we need some standard, platform independant way to access all the different MMUs that exist.)"

If I were you I would send Thor an email to see what he thinks about a standard MMU.library, it seems he has a lot of experience with MMUs :-)
I don't know the level of portability of this library, but it would be a good idea to try it.

BTW reimplementing Prometheus.library for AROS would be great... and later aplying the openpci.library wrapper, of course.

[Crumb]

Cool snapshot! :-)

I don't plan to install Linux and as there's no gcc that can select different targets (AROS/68k, AROS/i386, OS3.x, WarpOS, PowerUP, MorphOS, OS4) I doubt that I'll be able to compile anything for AROS...