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?

[xeron]

Endianness doesn't matter. You could make an x86 OS with integrated 68k emulator along the same vein as MOS and OS4, if you wanted.

[bloodline]

Crumb wrote:
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?

Yes, exactly like MOS and OS4.

[bloodline]

xeron wrote:
Endianness doesn't matter. You could make an x86 OS with integrated 68k emulator along the same vein as MOS and OS4, if you wanted.

But the 68k code would fail when if tried to make an AROS x86 function call since the byte order in the data structures would be backwards.

Unless you have a better idea... if so I would love to have you join teh AROS team and develop your idea :-)

-Edit- You *could*make a Big Endien version of AROS x86, but that would have a performance penalty...

[4pLaY]

The 68k version of AROS havent been updated since 97 so no :/ anyone is free to port it if they wish =) would be fun to see how AROS did on my A1200.

[bloodline]

4pLaY wrote:
The 68k version of AROS havent been updated since 97 so no :/ anyone is free to port it if they wish =) would be fun to see how AROS did on my A1200.

That's not quite true. The Palm version has been updated and boots, this uses the 68k :-)

But the Amiga version of AROS has not been developed for a while... Maybe if someone wanted to donate a working ZII network card for Johan's A3K he could get AROS booting on the Amiga :-)

[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).

[xeron]

bloodline wrote:
But the 68k code would fail when if tried to make an AROS x86 function call since the byte order in the data structures would be backwards.

No it wouldn't since you take that into account when you write the emulator.

Unless you have a better idea... if so I would love to have you join teh AROS team and develop your idea :-)

No chance. I'm not interested in AROS. It seems like a really nice project, but I have OS4 :-)

[bloodline]

No chance. I'm not interested in AROS. It seems like a really nice project, but I have OS4

Without any code to support your claim, I have to say you are wrong :-)


@Crumb:

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!!! :-D

[falemagn]

xeron wrote:
Endianness doesn't matter. You could make an x86 OS with integrated 68k emulator along the same vein as MOS and OS4, if you wanted.

Sorry, no, you can't, unless the whole AROS and all of its apps, current and future, accessed memory in big endian mode, much like Amithlon does. That would of course mean a big speed penalty. Such a penalty is ok for an emulator, it's not ok for a general purpose OS and its applications.

If AmigaOS (and thus AROS) didn't expose its internal structures and if it let apps access functionalities only via function calls, then you probably convert function calls parameters from big to little endian, 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. The only solution is a sandbox.

[xeron]

Hmmm... oh yeah. I take it back.

[Georg]

Sorry, no, you can't, unless the whole AROS and all of its apps, current and future, accessed memory in big endian mode, much like Amithlon does. That would of course mean a big speed penalty. Such a penalty is ok for an emulator, it's not ok for a general purpose OS and its applications.

I'm not quite so sure whether this would really have such a big speed impact, Fabio. It's hard to say, but I would think 95 % native speed for most applications might (if someone tried) not necessarily turn out to be completely unrealistic.

[falemagn]

I'm not quite so sure whether this would really have such a big speed impact, Fabio. It's hard to say, but I would think 95 % native speed for most applications might (if someone tried) not necessarily turn out to be completely unrealistic.

I think a more realistic figure is around 20-25%, at least this is what some tests I did with Amithlon and Martin Blom's compiler showed some time ago. This is for two reasons:  

1) there are more instrunctions to execute, and more memory accesses to do every time a variable is fetched from the stack or main memory;

2) Program's size increases, whilst the processor instruction cache stays the same, which means that a functionally more little part of a given program fits in the cache at any given time, which in turn means that there are more cache misses.

I think all that is unacceptable.
[/list]

[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.