Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
What makes you think Photoshop has to be rewritten for ARM? You don't write your code for a specific CPU for the most part, unless it's in Assembly or something.
I admit that I'm not a programmer, but I don't believe for a second that it's like switching a button in a compiler. It's taking companies years to just switch their software from 32 to 64 Bit.
Photoshop is already being rewritten for that architecture. You can download a version today.
Even so, It's still a far cry from a Mac on ARM version. Do we have reason to believe that porting Photoshop for Windows on x86 to MacOS on x86 was an easy task?
 
What makes you think Photoshop has to be rewritten for ARM? You don't write your code for a specific CPU for the most part, unless it's in Assembly or something.
It already has been.

 
I admit that I'm not a programmer, but I don't believe for a second that it's like switching a button in a compiler. It's taking companies years to just switch their software from 32 to 64 Bit.

Even so, It's still a far cry from a Mac on ARM version. Do we have reason to believe that porting Photoshop for Windows on x86 to MacOS on x86 was an easy task?
More likely they ported photoshop on PowerPC to photoshop on x86 for Mac. It’s a lot easier to port from one architecture to another than it is to port from one operating system to another.
 
  • Like
Reactions: Justanotherfanboy
Forgive the ignorance, as I am not a software engineer, but what will this mean for the pro audio community like those in recording studios that run Pro Tools, Cubase, Studio One, Ableton Live and all the other digital audio workstations? Also how will it impact all the 3rd party developers that create plug-ins for these DAWs in the VST, AAX and AU formats? Is this a disaster on the horizon? It sure seems like Apple likes to continually flirt with catastrophes.
 
So there no "x86 only" software.

Mmmm, depends, this it's a pretty broad assumption, like to said Java runs everywhere w/o recompilation, likewise you may use either CPU specific instructions which define an algorithm behavior, encryption and big endia/Little endian it's just one on many examples, we don't talk about web services transactions, but those doing math or Bitcoin will illustrate you a bunch of utilities (like tesselation) that requires platform custom code and can't translate "on the fly'.

usually write "High level programming language" like C/C++/ObjectiveC/Swift/Java/Kotlin.

Likely with Java/kotlin exception all those provides "optimization flags" so the llvm compiles analyze the code and by itself implementation CPU extension, a common situation are parallelism and maths, I'll need to write a think book with the few of them.

As others have noted, this will be a staged roll-out, with the most powerful Mac models (the ones being used in corporations) being the last to migrate off of native x86 CPUs.

I don't buy Apple switching to ARM as they did when adopted x86 from (actually conceptually superior) powerpc, but maybe cook has a plan "just in case' the iPad loses its magic, like M$ rollout in parallel an ARM optimized macOS-arm platform only running catalyst applications as alternative safeguard strategy to an hypothetically declining iPad market, likewise the Rich iPad App store ecosystem brings macOS-x86 fresh air of new apps reverting macOS App store sad decline.

An ARM Mac won't be an alternative to an Mac pro iMac 27, MBP even high end Mac Mini, but would be ideal for low-end market (or iPad switching users, as also a side effect from catalyst is users abandoning iPads to enjoy more comfortable work-oriented device).

CISC typically uses microcode to break down these complicated instructions into simpler RISC-like instructions

Not always sir (I follow your post, but I won't assume an stake on your claims), I assume you likely retired, otherwise you should aware what Intel and AMD do adding more and more Gates (an modern x86 core easy cuadruplicate am ARM core).

Code execution optimization takes many strategies, like decode cisc to risc and then implement an optimized execution pipeline, is something working since i486 (and inspired in part by WISC CPU -itanium-), but modern CPU go beyond binary decomposition and recomposition, while predictive instruction sequence can improve IPC in pipeline execution models, newer CPU also execute some complex instructions deliberately in an asic often in an single cycled, even ARM CPUs follows this strategy but while cisc/WISC CPU can implement it deliberately ARM only does in pipelines as part of it's predictive execution branch, it gives cisc/WISC CPU an little edge over ARM, an edge that requires binary optimization sometimes.

Considering we are at a blink to leave behind the Von Neumann architecture (mostly thanks to ml/ai/cues), reinvent the scalar CPU is not a long term paying strategy.

I have few questions, for you sir, with due respect, where are macOS leaks pointing out apple is testing ARM CPUs beyond the PCH/SMC (aka t1/t2) controller? Why we have some AMD Zen APUs there?

You are familiar (and likely meet they) with Jim Keller and Mike Filippo? ARM CPUs? Right, AMD Zen... Right , yes Keller was Filipino chief while crafting Zen at AMD, if Apple can hire someone who knows how to improve or develop AMD - Zen licensed architecture, is Filippo, he knows Zen better than ARMs, despite his work crafting an x86-feature/performance competing ARM CPU, it was just monts of work, while Zen means years of experience.

Licensing Zen from AMD had Sense, as the CPU platform implies almost negible modifications to macOS (some of which seems done, ask Hackintosh-ers now capable to run macOS on AMD , as the never could until 2 yr ago).

I don't buy the ARM platform would bring macs that big advances you claim, every Von Neumann system implementation has its days numbered, do you want Innovation? Go hybrid, asic/fpga/nvram/many micro cores/integrated storage, in the future system ram, CPU, GPU, TPU, flash storage will reside in the same chip complex, you need more power, you add more of these hybrid complex, not just more ram etc.

My regards sir just in case you're who you claimed to be.
 
Last edited:
I
Forgive the ignorance, as I am not a software engineer, but what will this mean for the pro audio community like those in recording studios that run Pro Tools, Cubase, Studio One, Ableton Live and all the other digital audio workstations? Also how will it impact all the 3rd party developers that create plug-ins for these DAWs in the VST, AAX and AU formats? Is this a disaster on the horizon? It sure seems like Apple likes to continually flirt with catastrophes.

The best/worst scenario it only means some friends trashing their iPads for that cute enduring ARM MacBook, one that only run catalyst apps (and very few native macOS-arm apps).
 
  • Like
Reactions: AlumaMac
Not always sir (I follow your post, but I won't assume an stake on your claims), I assume you likely retired, otherwise you should aware what Intel and AMD do adding more and more Gates (an modern x86 core easy cuadruplicate am ARM core).

Your response makes no sense. I said CISC typically uses microcode. You responded “not always.” That’s what “typically means.” Not always.

However, it has been several decades since there has been a commercial CISC processor that did NOT use microcode. Every Intel and AMD processor has for at least 25-30 years.

Not sure why you mention “gates,” but you should know that “gates” are an unreliable measure of anything. There is no agreement on what a “gate” means, so people count transistors, not gates.

As for why Intel/AMD use more, it’s because they need to - the instruction decoder, microcode ROM, complicated memory contention circuits, etc. all require it. But that doesn’t mean they aren’t using microcode. They certainly are. You can even see the microcode ROMs on die photos - they are quite visible.

Code execution optimization takes many strategies, like decode cisc to risc and then implement an optimized execution pipeline, is something working since i486 (and inspired in part by WISC CPU -itanium-), but modern CPU go beyond binary decomposition and recomposition, while predictive instruction sequence can improve IPC in pipeline execution models, newer CPU also execute some complex instructions deliberately in an asic often in an single cycled, even ARM CPUs follows this strategy but while cisc/WISC CPU can implement it deliberately ARM only does in pipelines as part of it's predictive execution branch, it gives cisc/WISC CPU an little edge over ARM, an edge that requires binary optimization sometimes.

Why are we talking about WISC? What complex instructions do you think execute in a single cycle? What is your definition of complex instruction? (Something with a memory address in it, for example? Then no way it executes in a single cycle. A “long” instruction? Then no way it executes in a single cycle (unless each component micro-Op happens to be scheduled simultaneously because of lack of dependency and available resources).



Considering we are at a blink to leave behind the Von Neumann architecture

You’re hilarious. Where do you get this stuff?


I have few questions, for you sir, with due respect, where are macOS leaks pointing out apple is testing ARM CPUs beyond the PCH/SMC (aka t1/t2) controller? Why we have some AMD Zen APUs there?

There have been dozens of leaks over the years. There are WIDE OPEN indications:

- apple integrating iOS frameworks and Uikit
- apple dropping the 32-bit runtime
- carbon is gone
- KEXTs are now gone
- apps must now be signed
- the OS now is in its own read-only partition
- ARM chips do more and more (T2) in macs
- ABI changes in swift
- Mac App store
- bytecode
- catalyst

Apple is taking it step by step.

You are familiar (and likely meet they) with Jim Keller and Mike Filippo?

I worked with Jim Keller. He was responsible for the external bus and I was responsible for the integer execution units and instruction scheduler (and at one point the floating point execution unit).

I kind of lost what you are trying to say there at the end.

By the way, I don’t intend to be snippy. It’s just weird when people try to tell me how CPUs work.
 
I also think Apple might be underestimating how many users are using Windows software on their Macs, and emulating a different processor architecture is not a viable option.
Apple likely has a very good idea of how many are using Windows software on their Macs and know it’s a very tiny number of the millions of Macs sold every year.
I admit that I'm not a programmer, but I don't believe for a second that it's like switching a button in a compiler. It's taking companies years to just switch their software from 32 to 64 Bit.
It’s mostly like that, though. For anyone that’s been writing code in the way that Apple suggests and using Xcode, Apple’s done a LOT of good work at the compiler/linker level that means they know the intent of the code you’ve written and can produce efficient compiled code for any targeted chipset they support.

This hasn’t been an overnight thing, this has been over YEARS. As it’s been mentioned, because of all the work developers have had to do in order to match the requirements for Catalina, if you’ve got 64-bit only code running on Catalina, you’ve already had to do all the hard coding required to make the transition a lot easier for you.
Forgive the ignorance, as I am not a software engineer, but what will this mean for the pro audio community like those in recording studios that run Pro Tools, Cubase, Studio One, Ableton Live and all the other digital audio workstations? Also how will it impact all the 3rd party developers that create plug-ins for these DAWs in the VST, AAX and AU formats? Is this a disaster on the horizon?
In the near term, it won’t mean anything. Some of those developers have already said “DON’T UPGRADE TO CATALINA!!” because their app isn’t ready. For those folks, they already know... no new systems. They’ll continue to use the system that’s working wonderfully for them. Some may never have to be worried about ARM systems because some plug-in they depend on is 32-bit, not being developed anymore and won’t run under Catalina, much less an ARM system.

In the longer term, it just means that some that are still being developed will run on ARM in the future, others may not. But, it’s not like the audio world isn’t already familiar with “If your system works fine, don’t touch it!“ That new OS feature may be cool, but fouling up your money making system will cost a LOT more than the value of that cool feature :)

I knew someone that was creating on one of the old Performas long after it’s normal useful life because it worked, provided rock solid results and if it DID hiccup, they precisely how to fix it.
like M$ rollout in parallel
But, M$ does not have access to ARM based CPU’s anywhere near as performant as Apple has. They’re creating an opportunity, a reason for Qualcomm to do better, and hoping that Qualcomm will rise to the occasion. Until then, they’re doing a parallel rollout.
 
AFAIK Apple can't make an x86 chip without a license from Intel, which probably ain't gonna happen. AMD have a license for historical reasons -
FYI most x86 and AMD64 parents expired decades ago, Early 2000s to be exact, AMD actually licensed it's Zen platform to THATIC who sells these in the Chinese domestic market, but due politics this agreement comes to an abrupt end.

Not just AMD manufactures x86 CPU, via technology also does (wo need to license Intel or AMD), Zhaoxin is another manufacturer of x86-amd64 compatible CPUs who never licensed a single patent.
 
I admit that I'm not a programmer, but I don't believe for a second that it's like switching a button in a compiler. It's taking companies years to just switch their software from 32 to 64 Bit.

Even so, It's still a far cry from a Mac on ARM version. Do we have reason to believe that porting Photoshop for Windows on x86 to MacOS on x86 was an easy task?
32-bit to 64-bit is a lot harder than switching architectures, because you actually have to modify your data structures (otherwise everything is 64-bit or everything is 32-bit, depending on the language you are using and how you defined things, and that would be a bad idea).

Switching architectures is trivial as long as your code doesn’t contain in-line assembly, and doesn’t make assumptions about big endIan or little endIan data representation.

(And screw autocorrect for capitalizing the ”I” in those)
[automerge]1582595800[/automerge]
FYI most x86 and AMD64 parents expired decades ago, Early 2000s to be exact, AMD actually licensed it's Zen platform to THATIC who sells these in the Chinese domestic market, but due politics this agreement comes to an abrupt end.

Not just AMD manufactures x86 CPU, via technology also does (wo need to license Intel or AMD), Zhaoxin is another manufacturer of x86-amd64 compatible CPUs who never licensed a single patent.

Patents last 20 years from filing. Copyright does not (and copyright covers instruction sets).

Given that x86-64 (AMD64) was developed in the mid 90’s, even the very first patents couldnt expire “decades ago.”
[automerge]1582595910[/automerge]
FYI most x86 and AMD64 parents expired decades ago, Early 2000s to be exact, AMD actually licensed it's Zen platform to THATIC who sells these in the Chinese domestic market, but due politics this agreement comes to an abrupt end.

Not just AMD manufactures x86 CPU, via technology also does (wo need to license Intel or AMD), Zhaoxin is another manufacturer of x86-amd64 compatible CPUs who never licensed a single patent.
Also, Via does manufacture under license. As does Zhaoxin (e.g. https://www.wsj.com/articles/amd-to-license-chip-technology-to-china-chip-venture-1461269701)
 
Sir, with due respect, are you aware utility patents expires after 30 years, everything patented before 1990 is public domain now. Check USPTO.gov there two patents has my name.
Where to start where to start.
1) like I said, x86-64 couldn’t have been patented before 1990 since it wasn’t invented until the mid to late 1990s. I was working on it around 1999 or 2000 if I remember correctly.

3) utility patents expire 20 years from the date of filing. I direct your attention to the uspto below.

Now, someone who knows who I am is going to give you a hard time about your attempted mansplaining to me, but don’t take it personally.

  • *****
  • (2) TERM.—Subject to the payment of fees under this title, such grant shall be for a term beginning on the date on which the patent issues and ending 20 years from the date on which the application for the patent was filed in the United States or, if the application contains a specific reference to an earlier filed application or applications under section 120, 121, 365(c), or 386(c) from the date on which the earliest such application was filed.
  • (3) PRIORITY.—Priority under section 119, 365(a),365(b), 386(a), or 386(b) shall not be taken into account in determining the term of a patent.
 
Patents last 20 years from filing. Copyright does not (and copyright covers instruction sets).

Given that x86-64 (AMD64) was developed in the mid 90’s, even the very first patents couldnt expire “decades ago.”
No sir, x86 instructions set is not covered by copyright laws, Google and Oracle have conflicting opinion about but yet the justice supported Google, and rights on a language definition do not extend to the symbols, you can use the same symbols and just name different to avoid not copyright but name brand licenses. AMD64 was released 2003 but most from it's related patents dates back 1990s, BTW AMD do not need Intel approvals to license it's remaining patents, while Intel can't do the same, that explains why we have Zen CPU licensed and no Pentium CPU licensed.
[automerge]1582596888[/automerge]
someone who knows who I am is going to give you a hard time about your attempted mansplaining to me, but don’t take it personally.
With due respect sir, I'm not looking employment.
 
No sir, x86 instructions set is not covered by copyright laws, Google and Oracle have conflicting opinion about but yet the justify supported Google, and rights on a language definition do not extend to the symbols, you can use the same symbols and just name different to avoid not copyright but name brand licenses. AMD64 was released 2003 but most from it's related patents dates back 1990s, BTW AMD do not need Intel approvals to license it's remaining patents, while Intel can't do the same, that explains why we have Zen CPU licensed and no Pentium CPU licensed.

With all due respect, you don’t know what you are talking about. I was there. I know what was invented when. And you haven’t seen the AMD-Intel crosslicense. And you think patents last 30 years. And that ISA mnemonics aren’t copyrightable?
 
utility patents expire 20 years from the date of filing. I direct your attention to the uspto below.
If you hold any utility patent you should aware (as Wikipedia rightful cites) patent term is not uniform, on some jurisdiction last 6 year's, on others 30yr maximum, in the US, it's right 20yr, but this time is not from filling, as the systems extend it as compensation on prosecution delays due USPTO backlog, or or pendency Time. So are not uncommon patents which rights extend beyond 26yr (as my first patent).
[automerge]1582597473[/automerge]
And that ISA mnemonics aren’t copyrightable
Search 'Oracle vs Google"
 
If you hold any utility patent you should aware (as Wikipedia rightful cites) patent term is not uniform, on some jurisdiction last 6 year's, on others 30yr maximum, in the US, it's right 20yr, but this time is not from filling, as the systems extend it as compensation on prosecution delays due USPTO backlog, or or pendency Time. So are not uncommon patents which rights extend beyond 26yr (as my first patent).
[automerge]1582597473[/automerge]

Search 'Oracle vs Google"
you are going to fall back on Patent Term Adjustment. Fine. Technically it lasts from 20 years from the filing date if the earliest patent application to which certain types of priority are claimed, plus a certain number of days depending on certain types of delays in the patent office (which never adds up to ten years).
As for internationally, any country that’s a member of the WPO treaty (which is any country where AMD or Intel has patents) is a 20 year term as well.
 
Last edited:
32-bit to 64-bit is a lot harder than switching architectures, because you actually have to modify your data structures (otherwise everything is 64-bit or everything is 32-bit, depending on the language you are using and how you defined things, and that would be a bad idea).

Switching architectures is trivial as long as your code doesn’t contain in-line assembly, and doesn’t make assumptions about big endIan or little endIan data representation.

(And screw autocorrect for capitalizing the ”I” in those)
[automerge]1582595800[/automerge]


Patents last 20 years from filing. Copyright does not (and copyright covers instruction sets).

Given that x86-64 (AMD64) was developed in the mid 90’s, even the very first patents couldnt expire “decades ago.”
[automerge]1582595910[/automerge]

Also, Via does manufacture under license. As does Zhaoxin (e.g. https://www.wsj.com/articles/amd-to-license-chip-technology-to-china-chip-venture-1461269701)
THATIC is the one who licensed Zen, Zhaoxin Is not related to Zen. Click read the full article before posting.

Zhaoxin is related to Via, not AMD.
 
... That should give you a hint.

Talking about hints, I asked you why we have AMD APU hints in macOS beta and no single Hity about ARM? at least refertence to ARM's GPUs should be there, dont you think?

Why?
[automerge]1582598524[/automerge]
Fair enough. they have Vias fab license as it turns out. They don’t need their own. They are also owned by via.
At least we made progress... Ah, THATIC licensed ZEN, not Core, dont forget that.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.