Welcome, Guest. Please login or register.

Author Topic: AROS 68k EMU  (Read 5781 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline falemagn

  • Sr. Member
  • ****
  • Join Date: May 2002
  • Posts: 269
    • Show all replies
    • http://www.aros.org/
Re: AROS 68k EMU
« on: February 03, 2004, 02:11:19 PM »
Quote

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.
 

Offline falemagn

  • Sr. Member
  • ****
  • Join Date: May 2002
  • Posts: 269
    • Show all replies
    • http://www.aros.org/
Re: AROS 68k EMU
« Reply #1 on: February 03, 2004, 03:34:44 PM »
Quote
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]