Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Iridium Banner AMIStore App Store A1200/A600 4xIDE Interface

AuthorTopic: MorphOS on x86???  (Read 7811 times)

0 Members and 1 Guest are viewing this topic.

Offline thecount22

Re: MorphOS on x86???
« Reply #75 on: August 01, 2012, 02:44:00 PM »
Quote from: Akiko;701708
According to takemehomegrandma , MorphOS is moving to Arm.
Sounds like a good idea to me.
 

Offline dreamcast270mhz

Re: MorphOS on x86???
« Reply #76 on: August 01, 2012, 03:46:43 PM »
SOunds fine to me, but I do enjoy my new MacBook thoroughly. I just want a definite decision at this point, no speculation. But if it moves to x86 and PPC goes unsupported, it will be a long time before I want to use MorphOS. MorphOS is a waste on modern HW, it definitely is not ready for use on a more powerful system as the OS needs to mature, just like a good Parmigiano-Reggiano. Once MorphOS is able to incorporate some modern OS features then we can talk about a move, IMHO.
My machines:
PowerMac G4 MDD 1.5ghz 1.25GB 10.5.8 & MOS 2.7
Mac Mini C2D 10.6.8 2GHz 3GB 250GB HDD
MacBook Retina 16GB 256GB SSD 10.8
iPad 2
Underground Gamer invites (a classic game site) PM

Need a part for a PC or Mac? PM me, I\'ll let you know if I come across it.

OS X trumps Windows on every level.

MorphOS, OS4 and Classic Amiga systems are the only ones who are real \'Amigas\', not that joke AROS or Amiga Forever.
 

Offline psxphill

Re: MorphOS on x86???
« Reply #77 on: August 01, 2012, 04:57:22 PM »
Quote from: thecount22;701788
And this assumption is based on what facts exactly?

You can't have a single library base that can be called from x86 or 68k.
 
The only option would be to have all library bases called as 68k and have a switch from x86->68k->x86 when you called an x86 library from an x86 piece of code. However this would introduce a huge overhead for every call.
 
You would also have to include a 68k stub when using SetFunction(), so the code would not be source compatible. You can't call a different function as something might have SetFunctioned SetFunction(). You can't have a different library base for 68k and ppc programs as the libraries data is also stored in the library base.
 
Anyway, good luck.
 

Offline itix

Re: MorphOS on x86???
« Reply #78 on: August 01, 2012, 05:59:16 PM »
Quote from: psxphill;701806
You can't have a single library base that can be called from x86 or 68k.
 
The only option would be to have all library bases called as 68k and have a switch from x86->68k->x86 when you called an x86 library from an x86 piece of code. However this would introduce a huge overhead for every call.

The overhead is tiny. In MorphOS all old AmigaOS API calls are called as 68k from PPC code and the overhead is negligible. Overhead is so small that even OS4 cant beat it with interfaces.

Quote

You would also have to include a 68k stub when using SetFunction(), so the code would not be source compatible. You can't call a different function as something might have SetFunctioned SetFunction(). You can't have a different library base for 68k and ppc programs as the libraries data is also stored in the library base.

Anyway, good luck.

SetFunction() is trivial. In MorphOS you can patch 68k functions by PPC or 68k code. You have to include a 68k gate to install PPC native patch but internally 68k code is never executed in PPC -> PPC calls. PPC native patches run without performance loss and on the other hand 68k SnoopDos is fully functional in MorphOS if you dont happen to have PPC native port on your HD.

Not being source compatible doesnt matter. You cant port MCP or MCX or SnoopDos from 68k to PPC or x86 or ARM without making changes to patch code. In 68k arguments are passed in 68k registers and they often involve hand written machine code.
« Last Edit: August 01, 2012, 06:05:09 PM by itix »
My Amigas: A500, Mac Mini and PowerBook
 

Offline psxphill

Re: MorphOS on x86???
« Reply #79 on: August 01, 2012, 09:11:10 PM »
Quote from: itix;701821
The overhead is tiny. In MorphOS all old AmigaOS API calls are called as 68k from PPC code and the overhead is negligible. Overhead is so small that even OS4 cant beat it with interfaces.
 
 
 
SetFunction() is trivial. In MorphOS you can patch 68k functions by PPC or 68k code. You have to include a 68k gate to install PPC native patch but internally 68k code is never executed in PPC -> PPC calls. PPC native patches run without performance loss and on the other hand 68k SnoopDos is fully functional in MorphOS if you dont happen to have PPC native port on your HD.
 
Not being source compatible doesnt matter. You cant port MCP or MCX or SnoopDos from 68k to PPC or x86 or ARM without making changes to patch code. In 68k arguments are passed in 68k registers and they often involve hand written machine code.

It's got to execute the 68k gate, because it doesn't know what the code is doing. You can dynamically recompile it, but you've still got some lookups to do to find the native code. Or you can put some heuristics in to find a standard gate and shortcut it. It's not just old libraries that this would have to happen for if you want to be able to drop ppc libraries in and have them used by 68k software. It could be any library that has ever been written.
 
You can write libraries completely in C, I wouldn't like to say how often in occurred but you don't need assembler at all (just compiler support for regparm).
 
The next problem is that we're actually talking about x86 not PPC. So all of your code is going to have to do endian conversions. You either go the amithlon route, but then software that needs to write little endian values will end up doing two conversions. Or you spend the rest of time changing code to do the conversion where necessary. Or you try to come up with a new compiler patch that allows you to selectively have little or big endian variables.
 
Because of the amount of effort, still being limited to single processor and no memory protection, how horrible all the compromises would be to get it working on x86 it's not going to happen. I can't see developers flocking to an operating system that is crippled with that amount of backward compatibility. You can't even support x64.
 
ARM is probably a better choice if you want to avoid the endian issues, but then you have new problems like lack of decent hardware. Rasberry Pi is cheap, but it's also not very good. Even the more expensive boards are pretty poor in terms of expandability. 64bit is also coming to ARM, but you'll be shutting yourself off from that too.
« Last Edit: August 01, 2012, 09:15:20 PM by psxphill »
 

Offline takemehomegrandma

Re: MorphOS on x86???
« Reply #80 on: August 02, 2012, 05:20:36 AM »
Quote from: Akiko;701708
According to takemehomegrandma , MorphOS is moving to Arm.


:confused: :confused: :confused:

Uh? WTF?
MorphOS is Amiga done right! :)
 

Offline thecount22

Re: MorphOS on x86???
« Reply #81 on: August 02, 2012, 06:42:24 AM »
Quote from: psxphill;701842
It's got to execute the 68k gate, because it doesn't know what the code is doing. You can dynamically recompile it, but you've still got some lookups to do to find the native code. Or you can put some heuristics in to find a standard gate and shortcut it. It's not just old libraries that this would have to happen for if you want to be able to drop ppc libraries in and have them used by 68k software. It could be any library that has ever been written.

You can write libraries completely in C, I wouldn't like to say how often in occurred but you don't need assembler at all (just compiler support for regparm).

I am not familiar with this terminology so I really can't comment.

Quote from: psxphill;701842
The next problem is that we're actually talking about x86 not PPC. So all of your code is going to have to do endian conversions. You either go the amithlon route, but then software that needs to write little endian values will end up doing two conversions. Or you spend the rest of time changing code to do the conversion where necessary. Or you try to come up with a new compiler patch that allows you to selectively have little or big endian variables.

The compiler suggestion is not realistic in my opinion, no one would seriously consider it. You could create abstractions (for example a library for x86 apps) on top of all this pretty easily.

Actually come to think of it what would be better is not another amiga operating system on x86 but something that feels like wine (but more stable) with 68k and ppc emulation. Having seamless integration between your native os apps and amiga apps would be ideal (integration with the filesystem, clipboard, windowing system (resize, minimize, maximize, etc),  networking stack). That way you avoid many of the problem like drivers, hardware support having to implement core os components like filesystems etc...

Quote from: psxphill;701842
Because of the amount of effort, still being limited to single processor and no memory protection, how horrible all the compromises would be to get it working on x86 it's not going to happen. I can't see developers flocking to an operating system that is crippled with that amount of backward compatibility. You can't even support x64.

See my previous comment, I think much of this is not relevant if you aren't building the entire OS.

The Amiga is not likely to ever become mainstream again. Nearly all of the software that will ever be written for the amiga operating system already has been written. This is a sad but true story.

That said the amiga has tons to unique software that is worth salvaging. What most people really need is a stable, highly compatible, well integrated, convenient and non-cumbersome (not like uae) way of running amiga applications in concert with their more recent applications.

Quote from: psxphill;701842
ARM is probably a better choice if you want to avoid the endian issues, but then you have new problems like lack of decent hardware. Rasberry Pi is cheap, but it's also not very good. Even the more expensive boards are pretty poor in terms of expandability. 64bit is also coming to ARM, but you'll be shutting yourself off from that too.

Meh ARM seems like a good match to me seeing how PPC is starting to disappear quickly. At least for MorphOS
« Last Edit: August 02, 2012, 06:46:06 AM by thecount22 »
 

Offline itix

Re: MorphOS on x86???
« Reply #82 on: August 02, 2012, 10:20:31 AM »
Quote from: psxphill;701842
It's got to execute the 68k gate, because it doesn't know what the code is doing. You can dynamically recompile it, but you've still got some lookups to do to find the native code.


It has to check if 68k gate is there: if it is then it can directly continue executing PPC code. If 68k gate is not found then system switches to 68k emulation. No need to dynamically recompile anything. The 68k gate is just 68k trap instruction and pointer to PPC code. Application writers dont have to care about it. It is all embedded into operating system.

Quote
Or you can put some heuristics in to find a standard gate and shortcut it. It's not just old libraries that this would have to happen for if you want to be able to drop ppc libraries in and have them used by 68k software. It could be any library that has ever been written.


Calling PPC code from 68k is really simple and extremely efficient. All PPC native 68k ABI calls have 68k gate with 68k trap instruction. When trap instruction is executed emulator switches to direct PPC execution mode.

It is easier than you think.

Quote

You can write libraries completely in C, I wouldn't like to say how often in occurred but you don't need assembler at all (just compiler support for regparm).


All 68k libraries written in C I have ever seen always use some reg(a0, foobar) style argument passing which will not work on non-68k compilers.

Quote

The next problem is that we're actually talking about x86 not PPC. So all of your code is going to have to do endian conversions. You either go the amithlon route, but then software that needs to write little endian values will end up doing two conversions. Or you spend the rest of time changing code to do the conversion where necessary. Or you try to come up with a new compiler patch that allows you to selectively have little or big endian variables.


Endian conversion of course is real issue on x86 it will be faster than WinUAE or any real Amiga.

Quote

Because of the amount of effort, still being limited to single processor and no memory protection, how horrible all the compromises would be to get it working on x86 it's not going to happen. I can't see developers flocking to an operating system that is crippled with that amount of backward compatibility. You can't even support x64.


Of course cant and if MorphOS switched arch it would most likely drop all 68k (and PPC) binary compatibility including use of 68k gates.
My Amigas: A500, Mac Mini and PowerBook
 

Offline psxphill

Re: MorphOS on x86???
« Reply #83 on: August 02, 2012, 03:11:53 PM »
Quote from: thecount22;701892
Actually come to think of it what would be better is not another amiga operating system on x86 but something that feels like wine (but more stable) with 68k and ppc emulation.

This was my original point. What AROS is doing with integrating UAE in is the best way. Anything with a well defined API can then be shared between 68k & x86. So you'd be able to use a 68k filesystem, but you probably wouldn't be able to send packets to it from x86 code as each packet would need custom code for doing the endian conversions.
 
An assign in one environment could be pushed to the other.
And you'd need some way of launching a 68k process from x86 and vice versa, but this shouldn't be too hard.
 
However nobody has even bothered to add PPC emulation to UAE. For most people that would be all they actually need as they could run it on any host OS. Even an amithlon style Linux distro.
 

Offline thecount22

Re: MorphOS on x86???
« Reply #84 on: August 03, 2012, 12:35:59 AM »
Quote from: psxphill;701954
This was my original point. What AROS is doing with integrating UAE in is the best way. Anything with a well defined API can then be shared between 68k & x86. So you'd be able to use a 68k filesystem, but you probably wouldn't be able to send packets to it from x86 code as each packet would need custom code for doing the endian conversions.

 
Can we stop with the endian debate? It's quite clear that if you always do the conversion on x86 everything would work just fine, it can even be abstracted away in a set of libraries so the developer doesn't even need to think about it. The performance hit is of no real consequence. If you can think of any API that wouldn't work with this in mind post it here so we can discuss it.

I would argue that AROS is not the best way to integrate 68k software. If you are serious about running old Amiga 68k + PPC software and I don't mean just for nostalgia or as a curiosity, I mean for real actual use. You need to have it alongside your other modern applications (that most likely means Linux, MacOS X or Windows applications) and not some OS that is almost completely devoid of applications. That also means having good integration with the host operating system for example not having to copy files back and forth to a VM or running workbench in a window or fullscreen or being unable to do simple things like copy/paste. Think of speed like ARDI Executor (68k mac emulator) and seamlessness of Wine.

Quote from: psxphill;701954
An assign in one environment could be pushed to the other.
And you'd need some way of launching a 68k process from x86 and vice versa, but this shouldn't be too hard.
 
However nobody has even bothered to add PPC emulation to UAE. For most people that would be all they actually need as they could run it on any host OS. Even an amithlon style Linux distro.


See above.
 

Offline smerf

Re: MorphOS on x86???
« Reply #85 on: August 03, 2012, 05:04:39 AM »
Quote from: mingle;417488
Hi,

I'm probably stating the obvious and/or flogging a dead horse here, but is there any chance that MorphOS could appear for x86?

If not, what are the main reason for it not?

I can think of a few, but please feel free to let me know if there are any more obvious ones:

1: Lack of resources/developers
2: Difficulty of porting to such a large range of hardware (see point 1:).

I just think it'd be amazing if MorphOS was available for the cheap and powerful x86 hardware...

!

Cheers,

Mike.



Hi,

Why would you want to ruin a good PC with an Amiga Emulator for a Mac?

PC's already have a better operating Amiga Emulator called WinUAE, and guess what it is probably 10 times faster than MorphOS, and it really works, even I can use it.

Not only that but:

I think it would really be amazing if MorphOS really worked

smerf
I have no idea what your talking about, so here is a doggy with a small pancake on his head.

MorphOS is a MAC done a little better
 

Offline smerf

Re: MorphOS on x86???
« Reply #86 on: August 03, 2012, 05:15:47 AM »
Hi,

Oh Gawd!!

Here we go into the the endless debate of which OS is better.

Amiga Dos 1.0 wins. Makes all the newer OS's look like dawggy poo poo

Hey transition, you know the term take the bull by the horns, well I hate to say this but on this thread you got the bull by the tail, do you know what that means, you are receiving a lot ob bull poo poo.

smerf
I have no idea what your talking about, so here is a doggy with a small pancake on his head.

MorphOS is a MAC done a little better
 

Offline krashan

  • Full Member
  • ***
  • Join Date: Jan 2003
  • Posts: 247
  • Country: pl
  • Total likes: 0
  • Gender: Male
  • Hardware designer and programmer
    • Personal homepage
Re: MorphOS on x86???
« Reply #87 on: August 03, 2012, 05:19:15 AM »
Quote from: smerf;702042
Why would you want to ruin a good PC with an Amiga Emulator for a Mac?

1. MorphOS is not an Amiga emulator.
2. Software cannot ruin hardware it runs on.
Quote from: smerf;702042
called WinUAE, and guess what it is probably 10 times faster than MorphOS, and it really works, even I can use it.

3. Probably, but unfortunately it is not true.
4. MorphOS really works too. Check it for yourself, low quality of your posts may be improved then.