Is It Emulation or Not -- the Dilemma

[takemehomegrandma]

OK,

Here is the thread, so go at it: When you run software written for one computer (let us say an Amiga) on another computer (for instance a PC, MAC, or DEC PDP 11/40), what is it?

Depends.

If you run software written for Amiga on a Mac using MorphOS, which provides the complete Amiga environment and API's (minus Amiga custom chips etc) fully native on the Mac hardware, then it's not emulation, the software is being run native. The Amiga apps are scheduled by the same scheduler as those compiled directly for MorphOS, they all share the same resources, the same memory space, the same signalling system. There is no difference from an Amiga program and a MorphOS program in the way they are treated/handled, they all have full access to everything, they are both running directly on top of the OS (no layer in between), which is running directly on top of the HW. Everything is fully native!

If you run the Amiga software on a Mac using UAE sitting on top of the native environment, then it will run boxed in an emulated environment. UAE is software that tries to mimic the Amiga hardware, and the Amiga applications are then executed by that piece of SW inside its own box, shielded from the native system that lies underneath it.

On MorphOS you generally don't need to use emulators to run Amiga software. Games/apps that access Amiga custom chips directly (instead of going through the OS) will not run without an emulator like UAE though.

So, by "natively," you mean PPC opcodes only running on a PPC system.
Yep, that's native.
68k opcodes running on a PPC?  There's some level of emulation.

PPC opcodes running on a PPC system, is running native.

If you have a 68k program and you recompile it into being PPC instead, then you will have PPC opcodes running on a PPC system, fully native.

Both the above is how MorphOS does it. In other words, fully native.

If you on the other hand constructs a piece of program with the aim to mimic a physical 68k CPU through SW and run 68k opcodes using that, then you would have emulation. Just like a real CPU, it would have a Program Counter pointing to the next in line 68k opcode to be executed, it would have routines to deal with that opcode and all the others (instruction set), it would have the D0-D7 data registers and the A0-A6 address registers to be used by these opcodes, it would have the status register (signalling "overflow", etc), and it would have a chunk of "system RAM" allocated in a box where the 68k application(s) and their data resides, that this "CPU" can access. When one opcode is executed, registers are altered, "system RAM" is altered, the Program Counter in this "virtual CPU" increases to point to the next opcode in line. Since it's the 68k opcodes (unchanged) that are actually being executed, by a program that simulates a physical 68k CPU, it is emulation. The emulator itself would run native on the system, but the 68k code inside it would be emulated.

[OlafS3]

From the view of a user it is not so important if it runs "emulated" (UAE) or native. UAE running on modern hardware is pretty fast and you do not have any problems regarding speed. Of course is the integration of 68k in MorphOS (and AmigaOS) a nice thing because you can mix 68k and PowerPC (and add f.e. Arexx what is not possible when running 68k as sandbox). On the other hand it is not possible outside PPC so it is difficult to change the platform and you have to stay on PPC forever. So both concepts have advantage and disadvantages.

[danbeaver]

Sorry, but the hardware has always defined the computer and the owners of said hardware design get to name it. An Amiga is the hardware that Commodore sold. The operating system is superficial. If MorphOS (as in v 1.45) ran on an Amiga, that computer does not become a Morph computer; it is an Amiga running MorphOS.

[persia]

@danbeaver

Then you are saying that C=USA's Amiga is the true Amiga since they have the legal right to name it?

[desiv]

PPC opcodes running on a PPC system, is running native.

If you have a 68k program and you recompile it into being PPC instead, then you will have PPC opcodes running on a PPC system, fully native.

Both the above is how MorphOS does it. In other words, fully native.

Yes, we all know that.. ;-)

If you on the other hand constructs a piece of program with the aim to mimic a physical 68k CPU through SW and run 68k opcodes using that, then you would have emulation.

er..  OK..  Not sure why anyone would ever do that ..  But thanks for that... :crazy:

The real question is (and as far as I know really has always been the question) how does it run applications designed for the 68k Amiga (not with the aim to "mimic" anything, but with the aim to run on a 68k Amiga, as that's what they were when the software was released).

Obviously, if the option is available to re-compile, that's great.  But it's frequently not the option.

However, the question about the different emulation layers in MorphOS has been answered already here..

Thanx,

desiv

[danbeaver]

Sorry, but the hardware has always defined the computer and the owners of said hardware design get to name it. An Amiga is the hardware that Commodore sold. The operating system is superficial. If MorphOS (as in v 1.45) ran on an Amiga, that computer does not become a Morph computer; it is an Amiga running MorphOS.

[danbeaver]

@danbeaver

Then you are saying that C=USA's Amiga is the true Amiga since they have the legal right to name it?

Hmm, BRANDING?  Let's use my logic: Did CUSA design their hardware? Uh... No.  It is a frickin' Intel based chipset oft called a "PC."  Did they buy the name to sell stuff?    Uh...  yes, I suppose.  Is the stuff they sell original.  Well they are "copying" the case design one of the previous BRAND name owners.  Is their software an emulation? Yep.

And "Native" code?  Does the code define the hardware design?  Well, which came first the hardware or the code?  In the case of an ORIGINAL design, I vote that the hardware came first.  Heck, the Amiga team "emulated" Jay Miner's chip design on a Mac to work on the Amiga OS software, only to find that when the actual chips arrived, they did not behave like the "emulated" ones.  "Native code" means as much as "binary code."  It is a tree that blocks your view of the forest.  If "whatever software" runs on the designed hardware, the computer does not become a "whatever software" computer.  It doesn't matter were he grips it, the coconut does not become the swallow [vida supra].

P.S., Dilemma from Greek "Di" = two and "Lemma" = assumption, proposition, argument or theme.

[psxphill]

Hmm, BRANDING? Let's use my logic: Did CUSA design their hardware? Uh... No. It is a frickin' Intel based chipset oft called a "PC." Did they buy the name to sell stuff? Uh... yes, I suppose. Is the stuff they sell original. Well they are "copying" the case design one of the previous BRAND name owners. Is their software an emulation? Yep.

Most of that same argument can be used against Intel Mac's.
 

Depends.

If you have a 68k program and you recompile it into being PPC instead, then you will have PPC opcodes running on a PPC system, fully native.

Both the above is how MorphOS does it. In other words, fully native.

What MorphOS does for 68k software is emulation, it's not native. Alot of emulators dynamically recompile executables into native code, AFAIK including WinUAE.

[danbeaver]

Dude, I totally agree!  

As far as the Apple Mac and Intel...  that is what I described earlier as "muddled."  I mean to sell a product like a computer for a wider profit margin it makes sense to skip designing your own hardware and use "someone elses" standard platform (I have no idea who defines that standard).  This means cutting your R&D hardware staff and their costs.  You then just kludge your "Mac OS" to run on the new hardware and now you have a "new Mac." Now any advances (by others) to the hardware becomes YOUR advances; it is now YOUR 16 core 64 Gig USB 5.0 Mac Air_Pro_Heavy computer.

In fact that describes the issue of emulation: the Mac OS is now "emulated" on Intel hardware, just like MorphOS, RuninUAE, WinUAE, et cetera.

[psxphill]

In fact that describes the issue of emulation: the Mac OS is now "emulated" on Intel hardware, just like MorphOS, RuninUAE, WinUAE, et cetera.

With Intel Mac's the only time emulation comes into it is when running PPC applications. An Intel Mac is a thing in it's own right, it doesn't emulate itself when running applications compiled using the Intel Mac SDK.

[danbeaver]

With Intel Mac's the only time emulation comes into it is when running PPC applications. An Intel Mac is a thing in it's own right, it doesn't emulate itself when running applications compiled using the Intel Mac SDK.

 
Good Point!

Let's put it the way Apple tried to sue Microsoft over Windows:  "You then kludge the 'look and fell' of your operating system to run on whatever is the hardware flavor of the week.  Thus 'emulating prior code' to give the consumer the idea nothing has changed; you sell it as just  another 'improvement' to the Mac."

[Iggy]

Sorry, but the hardware has always defined the computer.

You keep saying that as a acticle of faith, but as someone with a background in th design and sales of computers I have a slightly different opinion.
In the early '90s my company was rapidly learning that we would need to design software that worked with an OS' drivers rather then hitting hardware directly.
While the code was still processor specific, everything else could be platform agnostic and still function.
And higher level code itself did not even require CPU specificity.
So no, the hardware does not define the system.
 
I can claim to have a Linux based system and this will still not describe the hardware.
Your statement is based on ideas that were getting old at the time of Commodore's demise.
They beome less valid each year.

[psxphill]

Let's put it the way Apple tried to sue Microsoft over Windows: "You then kludge the 'look and fell' of your operating system to run on whatever is the hardware flavor of the week. Thus 'emulating prior code' to give the consumer the idea nothing has changed; you sell it as just another 'improvement' to the Mac."

I'm not sure where you got your quotes from. In terms of Mac and Windows there is no code emulation. The case is all down to look and feel. Apple were upset because they licensed the look and feel from Xerox, while Microsoft developed applications for the Mac and then started working on something similar in secret. Big companies don't make money by being ethical.
 
If copying someone elses idea is bad then Linux is more evil than Microsoft.

[danbeaver]

Well I'm not sure what an "acticle of faith" is, nor that software has faith (agnostic).  But code does not define the hardware, and your non-specific code either worked like Java (JIT compiler) or was written in some binary that at some point reached specific hardware.  If your code was not compiled for the hardware, but was interpreted to run on the hardware, by whatever API or "other layer of software," then it was emulated.  Prior to compiling, all code is generic (in my experience, and no ASM doesn't need compiling), now whether it has Faith or is Agnostic is not for me to say.  But the hardware defines the computer.  The software, well just defines the software.

If the designers had made a hardware system and called it "Morph" and the subsequent OS was called "MorphOS," then it would be a Morph Computer.  As it is, Apple designed that hardware, Morph designed an "emulation layer," and low, and behold, it ran SOME software marketed for the Amiga (hardware) computer.

[takemehomegrandma]

From the view of a user it is not so important if it runs "emulated" (UAE) or native. UAE running on modern hardware is pretty fast and you do not have any problems regarding speed. Of course is the integration of 68k in MorphOS (and AmigaOS) a nice thing because you can mix 68k and PowerPC (and add f.e. Arexx what is not possible when running 68k as sandbox). On the other hand it is not possible outside PPC so it is difficult to change the platform and you have to stay on PPC forever. So both concepts have advantage and disadvantages.

Well, when all applications are running fully native (both Amiga and MorphOS), driven by the same scheduler, sharing the same memory space and system resources, then you can use tools like Snoopium for instance, data can be shared, and you can have various apps collaborating and working together (ARexx for instance) in a way that is not possible when running the Amiga apps under emulation.  

Running the 68k Amiga apps in an emulation sandbox like UAE is faster and easier to implement than having it native though, and UAE emulates the entire Amiga HW which makes it possible to run old apps and games that aren't really system friendly. It's not quite the same though, it's more like having two parallel systems in one.

However, when MorphOS migrates away from the PPC and maybe starts implementing none-Amiga features like true SMP, true MP, true 64-bit, etc, then this approach will probably the the only way.

[takemehomegrandma]

er..  OK..  Not sure why anyone would ever do that ..  But thanks for that... :crazy:

Why? Because you for some reason would want to recreate a working model of some hardware using software. Emulation! In this case some kind of a "virtual" 68k CPU.

Obviously, if the option is available to re-compile, that's great.  But it's frequently not the option.

That is de-facto what MorphOS does before running an Amiga 68k app (or dynamically while running). Not from sources obviously, but from binaries. No 68k opcodes are being executed, they are all PPC native, running natively on the OS, which runs native on the HW.

However, the question about the different emulation layers in MorphOS has been answered already here..

Indeed, if you want to explore the joys of emulation in MorphOS, you have numerous options; like UAE, C64, Sega systems, MAME, etc, etc.

However, if you just want to run none-HW-banging Amiga apps on MorphOS, then there is no need for emulation.