Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
All that software-level emulation and it still is playable. These chips must be damn good.

Ya, emphasize "all that software-level emulation" The more layers you have, the more trouble you can expect...But seems this going in the opposite direction instead.

The M1 is that gook, multiple layers is now considered a 'non-issue' really? All that talk in the history books just got snuffed out.
 


Codeweavers posted a blog post and video tonight showing off CrossOver running on an Apple M1 MacBook Air. This video shows Team Fortress 2 running on a new M1 MacBook Air:


CrossOver is software (based on Wine Project) that runs Microsoft Windows apps on the Mac by translating Windows APIs into their Mac equivalents. The Codeweavers team was able to run the current version of CrossOver on the new Apple M1 MacBook Air under Rosetta 2 to achieve this feat. Codeweavers maintains a compatibility database so you can see what might work under CrossOver. They were also able to run Quicken, Among Us, and Witcher 3.

Article Link: CrossOver Allows x86 Windows Apps to Run on Apple M1 Macs
Only Apple has the power to slowly kill-off x86. To be frank, it is about time that x86 is put down and laid to rest. An inefficient architecture, which has had various attempts to be killed-off. Not even Intel itself could do (I’m thinking of Itanium).

ARM is on its way to world domination! Go Apple, go ARM RISC!
 
Only Apple has the power to slowly kill-off x86. To be frank, it is about time that x86 is put down and laid to rest. An inefficient architecture, which has had various attempts to be killed-off. Not even Intel itself could do (I’m thinking of Itanium).

ARM is on its way to world domination! Go Apple, go ARM RISC!
As Microsoft showed the biggest hurdle to ARM was all the x86 code out there and the fact emulation sucked. This is why even though there as been ARM Windows for about two years not much has been done with it.

Also it isn't just that the M1 is ARM but that it is a SoC using an SSD.

It is such a design change that it looks like our concepts of Ghz and RAM requirements have gone right out the window - but part of that is likely due to the SSD. Page swaping is fact - insanely fast when compared to a platter drive and as good as the M1 is if it had to use a platter drive it, in all odds, would take a huge performance hit.
 
This makes me excited about all those Windows only games on steam! If this works well, I might not have to use bootcamp anymore, or even get rid of my PC.
I am placing my bets on services like Geforce Now for your Steam needs. Why simulate a PC when you can just stream the display of a real PC?

And Federighi hinted to this as well:
Federighi also suggested that Windows in the cloud could be a possible solution in the future,
 
  • Like
Reactions: pshufd
I am placing my bets on services like Geforce Now for your Steam needs. Why simulate a PC when you can just stream the display of a real PC?

And Federighi hinted to this as well:

If you want to run games, why not just have a PC in your home that you can just RDP into for playing games on old hardware? It should be less money than renting a server.
 
What's the difference between JIT translation and emulation?

Just-in-time compilation is a technique.
Emulation is a method with which we can execute code that is not written to natively run on a system.
Translation is the other method with which we can execute code that is not written to natively run on a system.

So... "just-in-time translation" reads like gibberish to me, to be honest. I understand "binary translation" and "just-in-time compilation" in their own different contexts... because one is a method and the other is a technique. They are different. People should not mix them up.

As for the difference between "translation" and "emulation", it's kind of fundamentally this:

Emulation attempts to make the host (target) system behave closer to the original (source) system. So say... if I'm "emulating" a PlayStation 2, that means I'm trying to make my PC "behave" like a PS2, down to how it's managing memory, timings, etc...

Translation, on the other hand, attempts to make the base code run on the target system without matching any behavior from the source system. So, say... if a piece of code is supposed to run for 2ms then pause for 1ms in the original source system, the target system may take 1ms for execution without pausing and that's acceptable.

Here's my poor attempt at making it more lay-man:

Emulation - you try to act like someone else, down to their behavior, habits, expressions, etc...
Translation - you follow someone else's instructions, but don't also try to copy their behavior, habits, expressions, etc...

So Apple's term of "translation" is fairly accurate. I wouldn't call Rosetta 2 an "emulation" layer because it doesn't attempt to make Apple Silicon behave like an x86 computer at all. In contrast, a PS2 emulator is an emulator because it does try to make my PC behave like a PS2, down to how slow it runs.

P.S.: look at it this way: "emulation" is kind of like "translation" but with more "restrictions" in place to make sure timings are not broken (timings are often the most critical thing in an emulator).
 
Just-in-time compilation is a technique.
Emulation is a method with which we can execute code that is not written to natively run on a system.
Translation is the other method with which we can execute code that is not written to natively run on a system.

So... "just-in-time translation" reads like gibberish to me, to be honest. I understand "binary translation" and "just-in-time compilation" in their own different contexts... because one is a method and the other is a technique. They are different. People should not mix them up.

As for the difference between "translation" and "emulation", it's kind of fundamentally this:

Emulation attempts to make the host (target) system behave closer to the original (source) system. So say... if I'm "emulating" a PlayStation 2, that means I'm trying to make my PC "behave" like a PS2, down to how it's managing memory, timings, etc...

Translation, on the other hand, attempts to make the base code run on the target system without matching any behavior from the source system. So, say... if a piece of code is supposed to run for 2ms then pause for 1ms in the original source system, the target system may take 1ms for execution and that's acceptable.

Here's my poor attempt at making it more lay-man:

Emulation - you try to act like someone else, down to their behavior, habits, expressions, etc...
Translation - you follow someone else's instructions

So Apple's term of "translation" is fairly accurate. I wouldn't call Rosetta 2 an "emulation" layer because it doesn't attempt to make Apple Silicon behave like an x86 computer at all. In contrast, a PS2 emulator is an emulator because it does try to make my PC behave like a PS2, down to how slow it runs.

My analogy.

You have a book written in Spanish and you can't read Spanish but you want to read the book.

So Emulation is where you have a Spanish to English dictionary and you look up the words as you read.
Just-in-time compilation is where someone who can read Spanish and speak in English reads the book and translates it to English on the fly and speaks it to you
Translation is where someone translates the book to English and you read the English version.
 
My analogy.

You have a book written in Spanish and you can't read Spanish but you want to read the book.

So Emulation is where you have a Spanish to English dictionary and you look up the words as you read.
Just-in-time compilation is where someone who can read Spanish and speak in English reads the book and translates it to English on the fly and speaks it to you
Translation is where someone translates the book to English and you read the English version.

Well, looking up the words as you read is actually a technique to achieve both emulation and translation. It's called "interpretation".

Someone translating the book to English from Spanish may still have to look up the words in a dictionary as well.

So yeah, the most distinct difference is still that... emulation and translation are "similar" in that they are both methods to be able to read something you don't normally understand.

And then you have various techniques to achieve that. Chief among them are interpretation (read-decode-execute), dynamic recompilation, and then there are ahead-of-time compilation, just-in-time compilation, etc...

What's happening underneath (just-in-time or whatever) is probably not too important at this point. I think the distinction between "emulation" and "translation" is more important, and people still mistake what's happening from time to time.

So... again, let's say... you speak English, and then there's a person who speaks Spanish.

Emulation means you don't just try to speak Spanish, you try to speak it like he does, complete with his accent, behavior, how slow he's saying it, etc...

Translation means you speak Spanish in your own way, with your own accent, and your own pace (faster or slower than the other guy).

The keyword here is "behavior". Emulation cares more about "behavior" than anything else in the world. If "behavior" is not closely matched, then your emulation is either incomplete or broken. Translation doesn't care about "behavior", as long as it runs, that's all that matters.
 
Well, looking up the words as you read is actually a technique to achieve both emulation and translation. It's called "interpretation".

Someone translating the book to English from Spanish may still have to look up the words in a dictionary as well.

So yeah, the most distinct difference is still that... emulation and translation are "similar" in that they are both methods to be able to read something you don't normally understand.

And then you have various techniques to achieve that. Chief among them are interpretation (read-decode-execute), dynamic recompilation, and then there are ahead-of-time compilation, just-in-time compilation, etc...

What's happening underneath (just-in-time or whatever) is probably not too important at this point. I think the distinction between "emulation" and "translation" is more important, and people still mistake what's happening from time to time.

So... again, let's say... you speak English, and then there's a person who speaks Spanish.

Emulation means you don't just try to speak Spanish, you try to speak it like he does, complete with his accent, behavior, how slow he's saying it, etc...

Translation means you speak Spanish in your own way, with your own accent, and your own pace (faster or slower than the other guy).

The keyword here is "behavior". Emulation cares more about "behavior" than anything else in the world. If "behavior" is not closely matched, then your emulation is either incomplete or broken. Translation doesn't care about "behavior", as long as it runs, that's all that matters.

Firefox was moving to JIT for Javascript in 2008. Javascript was interpreted at that time. The approach was to look for code that would be executed more than once and was of some complexity and that would be compiled to machine code and executed.

I worked on a project in the 1980s that did something similar for database execution. One thing about JIT - bugs can be catastrophic.
 
  • Like
Reactions: bill-p
Firefox was moving to JIT for Javascript in 2008. Javascript was interpreted at that time. The approach was to look for code that would be executed more than once and was of some complexity and that would be compiled to machine code and executed.

I worked on a project in the 1980s that did something similar for database execution. One thing about JIT - bugs can be catastrophic.

Yeah, JavaScript needs to be "translated" to machine code in order for it to work, and so... initially, the approach was to "interpret" it. Then just-in-time compilation was later utilized in major browsers to speed up execution time, but in general, that's what "translation" is.

It's been a while, but I used to contribute to a number of emulation projects when I was in college. They gave me much needed programming practice, and also a deeper look into how all this mumbo jumbo worked.

That was also when I learned the distinction between "emulation" and "translation". It was never quite clear how one differs from another, but it's clearer now.

I guess we can look at it this way: for a programming language, we want to "translate" it. For a gaming system, we want to "emulate" it. In the case of Rosetta, I think Apple is treating x86 like a language that needs to be translated, rather than a system that needs to be emulated.
 
I guess we can look at it this way: for a programming language, we want to "translate" it. For a gaming system, we want to "emulate" it. In the case of Rosetta, I think Apple is treating x86 like a language that needs to be translated, rather than a system that needs to be emulated.

Rosetta sounds a lot like FX!32 which is what Alpha/NT systems used to run x86 Windows programs on Alpha/NT. It did JIT but it saved the results so the more you ran your program, the faster it got. You could also schedule translation to run at night.

I started out on interpreted languages back in the 1970s so the idea was most familiar to me. Compiled execution came shortly thereafter. A lot of this stuff seems very old.
 
Only Apple has the power to slowly kill-off x86. To be frank, it is about time that x86 is put down and laid to rest. An inefficient architecture, which has had various attempts to be killed-off. Not even Intel itself could do (I’m thinking of Itanium).

ARM is on its way to world domination! Go Apple, go ARM RISC!
Being a marginal player in computers (8% world wide market share?) Apple is mostly irrelevant and definitely not in a position to kill x86.
 
From CrossOver‘s website:

. CrossOver is the easiest way to run many Microsoft applications on your Mac without a clunky Windows emulator. (Seriously, have you tried emulators? Do you like how they run on your Mac?) CrossOver works differently. It's not an emulator. It does the work of translating Windows commands into Mac commands so that you can run Windows software as if it were designed native to Mac.

That sure sounds like an emulator to me.
 
That sure sounds like an emulator to me.

No. CrossOver uses WINE. WINE is not an emulator... (it literally is in the name)

It's a translation/wrapper layer for things that are native to Windows but non-existent on Linux and Mac. Code are "translated" so they'll work, but they don't necessarily work like they do under Windows. That's why a lot of things break and even when they work, they don't work "right".
 
No. CrossOver uses WINE. WINE is not an emulator... (it literally is in the name)

It's a translation/wrapper layer for things that are native to Windows but non-existent on Linux and Mac. Code are "translated" so they'll work, but they don't necessarily work like they do under Windows. That's why a lot of things break and even when they work, they don't work "right".
Even emulators, like Sheepshaver, (MacOS 9 for the prebuilt 64-bit version, or Macintosh,js for 8.1) don't quite work the way you expect. Quirks that were the result of weird little system calls to obscure parts of the actual hardware can cause problems with emulation.
 
Even emulators, like Sheepshaver, (MacOS 9 for the prebuilt 64-bit version, or Macintosh,js for 8.1) don't quite work the way you expect. Quirks that were the result of weird little system calls to obscure parts of the actual hardware can cause problems with emulation.

Yeah, but fundamentally, emulation works under a stricter set of constraints than translation.

With translation, if it works, that's good enough. You can only consider something a "bug" in translation if it doesn't even work to begin with. What you just described above won't count as a translation bug because in the end, MacOS 9 itself still works.

With emulation, if something breaks, that means the original system (typically hardware) is misunderstood, or not well-documented. That causes the behavior of the emulator to be "different" from what you'd expect, and yeah, that counts as a "bug".

In short:
Translation = potentially imprecise, goal is to "just barely work", there's no guarantee that everything will "work well".
Emulation = absolutely must be precise, goal is to "work exactly as it did before", there's guarantee that a "complete" release must absolutely "work well".
 
  • Like
Reactions: DocNo
is there a way to run old Mac OS software on Big Sur? Guessing there might be a solution like crossover
 
Crossover has a 32-bit to 64-bit translation layer added for Catalina if that's what you mean by old.
I have a program for teaching that I used up until Mojave, but it stopped working with Catalina. So Crossover would allow this to work?
 
I have a program for teaching that I used up until Mojave, but it stopped working with Catalina. So Crossover would allow this to work?

Crossover is for Windows programs, not macOS programs.

It sounds like you want to run a 32-but macOS program on Catalina which doesn't support 32-bit macOS programs. I would run a Mojave virtual machine if the program is not graphics-intensive. I'm running a Mojave Virtual Machine to use iCloud Apps natively these days.
 
I am placing my bets on services like Geforce Now for your Steam needs. Why simulate a PC when you can just stream the display of a real PC?

And Federighi hinted to this as well:
My only concern with this is connectivity / lag issues. Regardless, I am all for subscription based streaming, however there are far too many and too expensive.
 
I’ve built Windows 10 running on a Raspberry Pi 3 (ARM) - there is an active community there. As it is, i am already able to run some x86 programs on my Pi as Windows on ARM is already supporting x86 programs via emulation. There is report saying that it will soon run x64 programs.

Because of this, there is a possibility that maybe Boot Camp can be resurrected...?
 
I’ve built Windows 10 running on a Raspberry Pi 3 (ARM) - there is an active community there. As it is, i am already able to run some x86 programs on my Pi as Windows on ARM is already supporting x86 programs via emulation. There is report saying that it will soon run x64 programs.

Yes, x64 emulation is coming (announced as beta for November, so any day now).

Because of this, there is a possibility that maybe Boot Camp can be resurrected...?
Maybe, but I think the bigger focus will be virtualization, not dual-boot.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.