Wenn Apple auf ARM umstellt?

paco

....
Leider kenne ich mich nicht weiter aus, deswegen die Frage:

Muss dann auch die Software neu programmiert/upgedatet werden, weil sie unter den ARM-Chips nicht mehr funktioniert oooder gibt es da keinen Zusammenhang und die bisherige Software läuft auch unter den ARM-Chips unverändert weiter?

Mag eine dumme Frage sein, aber wie gesagt, ich bin ja nicht vom Fach und sage deswegen schon mal vielen lieben Dank, danke.
 
Grundsätzlich müssen Anwendungen nicht neu geschrieben werden (zumindest, wenn sie nicht allzu hardwarenah sind), da zwischen Betriebssystem und Anwendung noch eine weitere Schicht existiert, die quasi vermittelt und umsetzt. Diese wird zusammen mit dem Betriebssystem an die neue Architektur angepasst werden müssen.
Hardwarenahe Software wie Treiber, etc. muss wahrscheinlich ebenfalls angefasst werden, selbst wenn Apple wieder eine zusätzliche Mittelschicht wie einst Rosetta dazwischen flanscht.
Und hier liegt die Crux; irgendwann werden auch da wieder alte Zöpfe abgeschnitten werden, um die Hardware effektiver nutzen zu können.

Muss dann auch die Software neu programmiert/upgedatet werden, weil sie unter den ARM-Chips nicht mehr funktioniert oooder gibt es da keinen Zusammenhang und die bisherige Software läuft auch unter den ARM-Chips unverändert weiter?


Um mit Radio Eriwan zu sprechen: Kommt drauf an. :)
 
Dann kann ich wieder mein Apple Newton verwenden. Der hat auch einen ARM!
:cool:
Ich denke, da wird man einiges umprogrammieren müssen. Windows wird man über BootCamp auch nicht mehr so einfach betreiben können?!
Nachdem ich aber Macs nur gebraucht kaufe, werden sich bei mir die eventuellen Probleme nach hinten verschieben.
 
apple hat einen vergleichbaren anwendungsfall, nämlich ein porogramm mit paralleller unterstützung von iOS und macOS, genannt "single binary", bereits 2018 auf der DC vorgeführt.

wie gut sie es machen werden weiß man nicht, genau so wenig wie man nicht weiß, ob nicht third party hersteller schneller als nötig intel verlassen werden. aber es geht natürlich grundsätzlich, dass man einfach alle apps so baut, dass sie eine zusätzliche plattform unterstützen.
 
wie gut sie es machen werden weiß man nicht
Es gab ja zwei vergleichbare Plattformwechsel in der Vergangenheit (68k—>PPC und PPC—>x86). Da würde ich persönlich sehr hohe Erwartungen an Apple haben und dementsprechend anspruchsvoll sein.

Damit meine ich nicht unbedingt, dass es in der Vergangenheit immer reibungslos lief aber ein heutiger Übergang zu einer neuen Hardwareplattform müsste einfach noch smoother und ohne größeren Ärger für den Anwender ablaufen. Alles andere wäre eine herbe Enttäuschung.
 
Zuletzt bearbeitet:
Grundsätzlich müssen Anwendungen nicht neu geschrieben werden (zumindest, wenn sie nicht allzu hardwarenah sind), da zwischen Betriebssystem und Anwendung noch eine weitere Schicht existiert, die quasi vermittelt und umsetzt. Diese wird zusammen mit dem Betriebssystem an die neue Architektur angepasst werden müssen.
Eine Anwendung besteht idR nicht nur aus Library-Calls, sondern sie "berechnet" ja auch etwas, was vom Compiler in ausführbahren Code der Zielarchitektur umgewandelt wird. Zeitkritische Dinge werden uU auch direkt in Assembler programmiert. In beiden fällen wird der x86 Code nicht einfach so auf einer ARM CPU laufen. Es wird also wieder etwas in Richtung Classic-Umgebung bzw. Rosetta geben müssen.
 
Zuletzt bearbeitet:
Eine Anwendung besteht idR nicht nur aus Library-Calls, sondern sie "berechnet" ja auch etwas, was vom Compiler in ausführbahren Code der Zielarchitektur umgewandelt wird. Zeitkritische Dinge werden uU auch direkt in Assembler programmiert. In beiden fällen wir der x86 Code nicht einfach so auf einer ARM CPU laufen. Es wird also wieder etwas in Richtung Classic-Umgebung bzw. Rosetta geben müssen.

sooo weit weg ist jetzt ein ARM processor von 86k auch nicht.

und vor allem hat macOS im gegensatz zu windows nicht das problem, dass intel noch patente auf SSE und das ganze gelumpe hat, man kann also notfalls OSX-intel applikationen auch unter 86k emulationen laufen lassen.
 
Muss dann auch die Software neu programmiert/upgedatet werden

die kurze antwort: ja.
im guenstigsten fall muss nur neu kompiliert werden, im unguenstigsten fall ist viel maschinenspezifisch programmiert, und man muss praktisch alles neu schreiben.
(ich denke, vieles wird sich mit eher kleinen anpassungen portieren lassen, der 2. fall duerfte weniger haeufig sein)
darueberhinaus koennte es auch einen emulator geben, der aber wohl nur fuer sehr anspruchslose software gut funktionieren duerfte.

fuer freunde bestehender software jedenfalls kein grund zur freude.
(und ich halte arm=lahm immer noch fuer wahr)
 
Wer glaubt, man könne die macOS (vorher OSX) Software "ohne Weiteres" auf einer ARM-Plattform nutzen, der täuscht sich.
Schliesslich geht auch nicht ohne Weiteres, dass x86-Software direkt auf einem iPad läuft (sowie umgekehrt). Portieren des Source-Code ist mit etwas Aufwand möglich - anschliessend wird es kompiliert. Wolfgang Palm hat z.B. seine nativen Software-Synthesizer erst auf iOS und dann (mit Hilfe von Hermann Seib) auf x86 portiert. So einfach 1:1 geht das nicht.

D.h.: Die Softwarehersteller (sofern sie es wollen, bzw. leisten können) werden "gezwungen sein" ihre Software vollständig auf die ARM-Umgebung umzuportieren und anzupassen, sofern ihre Unternehmen noch existent sein werden.
Bei VST-Plugins könnte es einfacher gehen (zumindest ist das so bez. Win-PC ./. macOS so), da diese "fast (GPU, etc. kommt noch hinzu)" OS-unabhängig sind und vom HOST verwaltet werden.

Auf der anderen Seite läßt sich aber Win10 auf einem ARM-Rasspberry Pi installieren und nutzen - da weiß ich nicht, in wie fern diese (mobile?) Win10-Version hierfür angepasst werden muss/te.
Ich bin schon lange nicht mehr im Bereich der Softwareprogrammierung unterwegs, daher möge man mich auch gerne korrigieren.
 
Zuletzt bearbeitet:
Bei VST-Plugins könnte es einfacher gehen (zumindest ist das so bez. Win-PC ./. macOS so), da diese "fast (GPU, etc. kommt noch hinzu)" OS-unabhängig sind und vom HOST verwaltet werden.
Hier werden dann möglicherweise keine macOS System Calls genutzt, sondern VST Calls, aber der ARM wird den x86 Code nicht einfach so ausführen können. Via etwas herumgesuche findet man schnell dies:

The emulation works completely transparently to both users and the programs they run. It uses the same WOW (Windows on Windows) technology that Windows uses to run 32-bit applications on 64-bit versions of Windows today. However, the x86-to-ARM emulation happens entirely in software.
 
Ich hab schon zwei Transformationen in der Mac-Welt durchgemacht: 68K -> PPC und PPC -> Intel. Ein drittes Mal brauch ich das (glaube ich) nicht.

Bisher dauerte das viele Jahre, bis so etwas abgeschlossen ist. Außerdem bedeutet das den Tod für das eine oder andere liebgewonnene Tool :sad: Von Hardware-Treibern für ältere Geräte will ich gar nicht erst anfangen.

Ich bin ja Berufsoptimist und lass mich gerne auch gerne eines Besseren belehren ... aber hier habe ich echte Zweifel.
 
Leider kenne ich mich nicht weiter aus, deswegen die Frage:

Muss dann auch die Software neu programmiert/upgedatet werden, weil sie unter den ARM-Chips nicht mehr funktioniert oooder gibt es da keinen Zusammenhang und die bisherige Software läuft auch unter den ARM-Chips unverändert weiter?

Mag eine dumme Frage sein, aber wie gesagt, ich bin ja nicht vom Fach und sage deswegen schon mal vielen lieben Dank, danke.
Generell werden viele Sachen so nicht laufen sondern in irgendeine Emulations-Engine, - dh alles was Intel ist, muss darin dann laufen. Was nativ geschrieben ist, wird schneller und besser passen und was älter ist, wird irgendwann nach ein paar Übergangsjahren mal verschwinden. Außerdem dann irgendwann auf den Nicht-ARM Rechnern nicht mehr laufen. Das passiert natürlich nur, solang alles auf ARM umgestellt wird - nicht wenn nur die kleinen Mobilrechner umgestellt werden, denn das wäre sehr viel sinnvoller - Zuerst die Air-Serie, dann die MBPs, weil de Leistung dann besser passt - und erst am Ende Desktop - vielleicht aber auch gar nicht Desktop, denn dort ist das Stromproblem egal - mobil hingegen würde ARM neue kompakte Designs ermöglichen bzw eine sehr lange Laufdauer ohne Stromzufuhr.

Man muss also genauer warten - ich denke aber Apple wird es so machen wir den Übergang von 68k auf PPC und von Motorola/IBM auf Intel - es sind jetzt schon Konversionen möglich, jedoch sind diese nur im Code ähnlich und müssen eigentlich in Swift gemacht worden sein, da sonst bestimmte Teile nicht rein passen, also hier ist noch alles relativ rudimentär.

Das ist jetzt wegen der Lib-Situation ein bisschen verteilt und dadurch bedingt wird das vermutlich nur bestimmte Programme zuerst betreffen und andere kommen nach - Simplere Tools wie Apples Recorder-App und so weiter - die werden zuerst laufen und ab iOS/iPadOS13 ist das offiziell dann auch etwas weiter - so auch mit MacOS in Catalina.

Dh - gerade bei Audio Kram ist das sowieso noch etwas haarig, das kommt nicht superschnell.

Doch - ARM ist nicht wie Intel. das erfordert andere Bedingungen, Apple hat nur bisher dafür gesorgt, dass es so wirkt als wäre es nahe und Apple will, dass Entwickler ihre Apps ständig anpassen - das wird aber bei Musik nicht so schnell gehen und unter Garantie werden einige Sachen dabei raus fallen und nicht mehr updated werden.
 
Was meinst Du mit 86k? Es gibt Intel x86 und Motorola 68k.

x86 meine ich natürlich.

und was ich noch ergänzen wollte: ängste, dass man für eine "völlig andere" prozessorplattform jetzt "alles neu" programmieren müsste, sind in jedem falle übertrieben. die unterschiede zwischen RISC und CISC bestehen doch heute nur noch in der theorie und machen sich in der praxis allenfalls durch unterschiedliche effektivität bei bestimmten befehlen bemerkbar.
 
x86 meine ich natürlich.

und was ich noch ergänzen wollte: ängste, dass man für eine "völlig andere" prozessorplattform jetzt "alles neu" programmieren müsste, sind in jedem falle übertrieben. die unterschiede zwischen RISC und CISC bestehen doch heute nur noch in der theorie und machen sich in der praxis allenfalls durch unterschiedliche effektivität bei bestimmten befehlen bemerkbar.
Naja, das Problem ist - so wie der Code jetzt ist, läuft nicht ALLES, daher muss man einiges anpassen - da gibt es 2 Möglichkeiten - das was da ist wird irgendwie konvertiert und läuft, ist aber nicht optimal, sondern nur "damit es geht" - die andere Version ist die puristische - man nimmt Apples Vorschlag und Idee und macht das mit der vorgesehen Library und die ist noch recht "klein", deshalb sind die Apps dafür auch in einer gewissen weise "simpel".
Aber - sie lassen sich erweitern und öffnen. Das wird sicher auch passieren - aber denke Apple wird genau diesen Weg gehen wollen. Wäre jedenfalls typisch.

Apple auf den ARM nehmen, kommt so ein Wortspiel noch irgendwie? Naja, ich beuge dem schonmal vor.
 
Zuletzt bearbeitet:
man wird dann im einzelfall erst wenn es soweit ist prüfen können, ob sich die (aufgrund des kleineres befehlssatzes auf der untersten ebene) "umständlichere" ausführung von code im zusammenwirken mit der insgesamt geringeren leistungsaufnahme irgendwie "rechnet" oder auch nicht.

auch die frage wieviele kerne man da maximal zusammenpappen kann und wie sich der marktpreis dafür entwickelt darf man bei der frage ARM vs intel nicht unterschätzen. vielleicht überholt ja der eine noch den anderen in irgendeinem aspekt sehr deutlich? ein königreich für eine glaskugel! :)
 
zum Vergleich kannst du dir die Situation bei Linux oder BSD anschauen, auch ux-basierte Betriebssysteme bei denen es seit langer Zeit Portierungen auf andere Prozessor-Archtitekturen gibt.
Da wird deutlich das nicht alles auf risc/arm-Cpus läuft, was für x86/amd64 programiert wurde.
Ein Problem sind die fehlenden CPU-Erweiterungen wie z.B. sse, solange ARM keine kompatiblen Alternativen bietet muß das alles emmuliert werden was dann ordentlich Rechenleistung benötigt.
 
Wenn die tatsächlich auf ARM umsteigen, frage ich mich, ob die PC-Welt dann weiterhin unbeeindruckt auf Intel/AMD-CPUs "sitzen" bleibt.
 
Wenn die tatsächlich auf ARM umsteigen, frage ich mich, ob die PC-Welt dann weiterhin unbeeindruckt auf Intel/AMD-CPUs "sitzen" bleibt.

Aber natürlich. Die PC-Welt hat ja noch nicht einmal durchgängig alle alten Zöpfe aus der 32-Bit-Ära abgeschnitten. :)

Alternativ wurde in den 90ern ja auch DEC-Alpha probiert, wollte aber keiner.

Grüße
Omega Minus
 
Da wird deutlich das nicht alles auf risc/arm-Cpus läuft, was für x86/amd64 programiert wurde.
Ein Problem sind die fehlenden CPU-Erweiterungen wie z.B. sse, solange ARM keine kompatiblen Alternativen bietet muß das alles emmuliert werden was dann ordentlich Rechenleistung benötigt.

und dennoch gibt es bereits seit 10 jahren viele applikationen, die es sowohl für iOS als auch für mac und windows gab - und davor für PPC.

unlösbar ist es also nicht, für mehrere plattformen zu optimieren. die mehrarbeit entsteht zunächst zunächst mal nur dadruch, dass man ja aktuell bei mac und pc die gleiche plattform hat, und wie du sagst dann SSE z.b. nur bei einem der hardwarehersteller ersatzlos wegfiele wenn apple umsteigt.

ich glaub nur nicht dran, dass es für uns als enduser unproblematisch wird, denn bislang hat man noch bei jeder umstellung irgendeine software "verloren". deswegen hat so manch einer auch noch seinen atari neben dem mac pro 2015 stehen.
 
An alle: Vielen lieben Dank für die vielen Antworten, freut mich!

Als Laie verstehe ich euch so: Die Chips/Chipsätze von ARM und Intel sprechen eine verschieden Sprache und verstehen sich so ohne Konvertierung nicht miteinander. Ergo müsste das OS entweder für beide simultan/doppelt geschrieben sein [was langfristig ja keinen Sinn ergibt, vielleicht jedoch zur Umstellung] aber langfristig dann nur den ARM anspricht + und daher dann muss deswegen auch die Software für die Plugins/Audio-Software neu/umgeschrieben werden?

Wenn ich recht verstehe - ich bin ja nicht vom Fach - wird diese Umstellung dann also nicht doch etwas schwieriger werden: Am Anfang wird es wohl - im besten Fall - so eine Art [ich bezeichne es mal unwissend als solches] doppeltes OS geben, wobei es da mit Plugins/Audio-Software wohl schon schwierig werden wird und das eine oder andere Plugin/Audio-Software nicht mehr funktionieren könnte/wird ...

... bedeutet für mich also, ich behalte dann mein aktuelles OS bei und friere den Rechner ein uuund werde nicht updaten, und wohl gezwungen sein, mir für neue Plugins/Audio-Software [oder die Updates] einen neuen Rechner mit diesem ARM-System zulegen zu müssen? Beziehungsweise, vielleicht bieten die Plugin/Audio-Software-Hersteller für eine gewisse Übergangszeit Versionen für beide an [was ich mir aber eigentlich nicht vorstellen kann]?
 
Zuletzt bearbeitet:
Für oder an alle, die das Thema auch beschäftigt.

Nachdem ich nächstes Jahr wohl meine beiden Macs um einen dritten ergänzen will oder eher muss [aus verschiedenen Gründen], war und ist dieses für mich eben ein beständiges Thema ... ein paar Wochen später, nachdem ich mir mit ein paar Leuten hin und hergeschrieben habe, komme ich für mich - und meine kleine Welt - zu folgendem:

- 2019 also zu 10.15 kommt ja sicher die Umstellung von einem 32/64-bit auf ein reines 64-bit-OS.

- 2020 also zu 10.16 kommen weitere Anpassungen an das iPad-OS, und das erste MacBook wird mit ARM-Chips erscheinen [late 2020]. Dabei wird ein Framework integriert sein, ähnlich wie damals Rozetta von 10.4 bis 10.6 [2006 bis 2011].

- 2021 also zu 10.17 sollen alle Macs auf die Apple-eigenen ARM-Chips umgestellt sein. Im Rahmen dessen kommt es zu weiteren kleineren Optimierungen, was vor allem die iPad-Apps betrifft: Die sollen dann auch auf den Macs mit 10.17 laufen.

- 2022 bis 2023 also zu 10.18/10.19 solle der Framework im Übergang noch beibehalten werden, und für das theoretische 10.20 soll dann auf ein reines ARM-OS umgestellt sein und ergo der Framework aus dem OS entfernt sein.

Das ist natürlich eine wage Roadmap, aber für mich eine schlüssige, an der ich mich orientieren kann und einen soften und funktionierenden Übergang auf diese ARM-OS-Geschichte kalkulieren kann.
 
... und noch mal vielen lieben Dank an alle, die mir hier dazu etwas geschrieben haben + hat mir sehr geholfen, um diese Umstellung und was das für mein Setup bedeuten könnte, zu verstehen!
 


Neueste Beiträge

News

Zurück
Oben