Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: Crumb on February 03, 2004, 12:44:25 PM
-
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?
-
And is the 68k version still being developed?
-
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.
-
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.
-
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...
-
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.
-
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 :-)
-
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).
-
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 :-)
-
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
-
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.
-
Hmmm... oh yeah. I take it back.
-
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.
-
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]
-
@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.
-
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?
Even if that were possible, the performance hit would be far below The emulator option I have already suggested.
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....
-
@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 wrote:
@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.
Several issues here:
1. Only the actuall function call would have any overhead, the function itself would be executed at fll speed natively on the CPU.
2. The Emulator would run as fast as any JIT, since only the actual OS function calls need to be passed to the Host OS, everything else runs via the JIT (as in MOS and OS4).
3. On an x86 system, you tend to have quite a bit of raw horsepower available even on low end systems.
4. By using an Emulator we do have the ability to use Games and Demos that hit the hardware.
5. By Big endien systems, you are refering to the PPC, which will be increasing in performance and AROS would have the advantage of harware hitting software, which is less likely to be ported to the new CPU anyway :-)
-
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.
-
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 wrote:
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.
AROS is suppsoed to be 100% compatible to 3.1. Getting the 68K version to work is a trivial task, 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?).
-
Crumb wrote:
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.
Look up openamiga.org :-)
That is the place to start such an idea :-)
-
I was going to say that I'm disappointed that AROS
had abandoned the idea of Classic Amiga
compatability. But after reading this thread maybe
not.
As I see it, any 'Amiga Like' OS, to have a chance
of being anything more than just another 'Also Ran'
has carry with it Classic Amiga compatability.
Without that compatability I don't really see any
reason for it. There are already a number of other
OS's that have very little support.
The Classic Amiga is a cult, look at how many ppl
now don't even consider the A1 a real Amiga.
No Classic compatability.
Without Classic compatability AROS ( IMHO )
is a waste of time, whats the point??
-
melott wrote:
I was going to say that I'm disappointed that AROS
had abandoned the idea of Classic Amiga
compatability. But after reading this thread maybe
not.
As I see it, any 'Amiga Like' OS, to have a chance
of being anything more than just another 'Also Ran'
has carry with it Classic Amiga compatability.
Without that compatability I don't really see any
reason for it. There are already a number of other
OS's that have very little support.
The Classic Amiga is a cult, look at how many ppl
now don't even consider the A1 a real Amiga.
No Classic compatability.
Without Classic compatability AROS ( IMHO )
is a waste of time, whats the point??
Once such a system is built for AROS, I don't see why it couldn't be ported to MOS and OS4.
-
@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.
-
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.
That is the only drawback with the emulator system.
Native tasks could not access the 68k libraries and devices.
But it would not take much work to make the *Special* 68k AROS build maybe a speical calling library on the Native side (That traps calls and directs them to the Emualtor)... hmmm I think it could be done actually... I have to assk Fabio though.
-
@Bloodline:
"Look up openamiga.org :-)
That is the place to start such an idea :-)"
added:
http://openamiga.org/forum/viewtopic.php?t=10 (http://openamiga.org/forum/viewtopic.php?t=10)
-
Personally, I don't see the reason for all the fuss about AROS ...
OK, I agree that's a serious project and the people involved are surelly skilled ...
But I have only one complain : Did you ever tried to run it on a 486 on the past ?
Before you laugh at me, let me say that I tried AROS some years ago when I have a 80Mhz 486 and that thing was damn slow !
Are you blaming the 486 ?
Don't.
On that same 486 I also run win95 and that was fast !
Usable.
OK, AROS is AMIGA like, now we have GHz CPU, blahblahbla, but I was totally putted by the lack of optimization of AROS ...
I really looked like a 68K emulator (which it isn't!)
-
ptek wrote:
Personally, I don't see the reason for all the fuss about AROS ...
OK, I agree that's a serious project and the people involved are surelly skilled ...
But I have only one complain : Did you ever tried to run it on a 486 on the past ?
Before you laugh at me, let me say that I tried AROS some years ago when I have a 80Mhz 486 and that thing was damn slow !
Are you blaming the 486 ?
Don't.
On that same 486 I also run win95 and that was fast !
Usable.
OK, AROS is AMIGA like, now we have GHz CPU, blahblahbla, but I was totally putted by the lack of optimization of AROS ...
I really looked like a 68K emulator (which it isn't!)
Since AROS is written in C, we did not use any optimisation until recently, sicne optimisation makes bug hunting more difficult.
THe Graphics drivers you would have seen were the first ones made and they only ued the most basic VGA display (which is slow on my 3Ghz machine). The Windows95 you were using would have had speciall build accelerated GFX drivers.
Basicly AROS only looked slow :-) I tried AROS on an old P75 a year ago and it was faster than my 1200 with a BlizzPPC :-)
-Edit- I'm not blaming the 486, it's a powerful CPU, I'm blaming the lack of AROS specific gfx drivers for your old GFX card.
-
I think I tried it with a 133 pentium loading from disk. I didn't try the CD version...
floppies are very slow...
-
@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 wrote:
@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?
The CD is currently required for an install. It's a very slow process, but it does actually work.
Before we include Virtual memory (Which I personally hate and have switched off on all my machines) 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.)
-
"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 wrote:
"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.
Well, as with everything in AROS... all it takes is someone to get on and do it :-/
Brand new PCI drivers are on the way:
(http://home.tu-clausthal.de/~misc/aros_pcitool.jpg)
-
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...
-
Crumb wrote:
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...
Well, AROS will come with GCC included for the HD install, so you could actually develop within AROS :-)