1. Foren
  2. Kommentare
  3. Mobile Computing
  4. Alle Kommentare zum Artikel
  5. › Macbooks: Apple erwägt…

Ausgerechnet Apple springt zwischen den CPU Arches...

  1. Thema

Neues Thema Ansicht wechseln


  1. Ausgerechnet Apple springt zwischen den CPU Arches...

    Autor: Geistesgegenwart 06.11.12 - 09:48

    Erst PowerPC, dann Intel, bald evntl. ARM. Und das ausgerechnet von Apple, die doch mit ihrem Focus auf Obj-C ein so gar nicht bytecode orientiert arbeiten. Dazu wird Java als "Deprecated" angesehen, darf also nicht im Appstore vertrieben werden.

    Vielleicht sollte Apple seine Entwickler weg vom native binary bringen, hin zu bytecode, IL oder JIT. Mit Java, C#, Python oder HTML5/JS. Oder aber ein LLVM binärformat verwenden, das man als als standalone .app ausliefern kann.

  2. Re: Ausgerechnet Apple springt zwischen den CPU Arches...

    Autor: gorsch 06.11.12 - 10:02

    Wo ist denn bitte der Vorteil Bytecode/VMs? Dass du ein paar MB für's Applikationsbinary sparst? Ist doch Mumpitz!
    Zwei Binaries in ein .app zu packen hat schon beim PPC/x86 Switch gut funktioniert.
    Abgesehen ist Apple schon heute einer der größten Nutzer und Mitentwickler von LLVM - und was macht LLVM? Native Binaries ausspucken. Just-in-Time oder Ahead-of-Time.

  3. Re: Ausgerechnet Apple springt zwischen den CPU Arches...

    Autor: fool 06.11.12 - 10:08

    Die Entwickler trifft das ja nicht besonders hart, die setzen halt noch ein Häkchen mehr. So war das bei der Umstellung auf Intel ja auch. Xcode macht den Rest. Gut, man muss portabel programmieren, aber das schadet grundsätzlich nicht :P

    Andererseits hat Apple natürlich durch die jahrelange Arbeit an LLVM und clang ideale Voraussetzungen für was du beschreibst...

  4. Re: Ausgerechnet Apple springt zwischen den CPU Arches...

    Autor: MarioWario 06.11.12 - 10:18

    Erst MOS Technology (6502) -> Motorola (68xxx) -> Power PC (601/++) -> intel (CoreDuo) -> ARM ?
    Haben auch nicht mit Objective C angefangen:
    GNU C Compiler -> MPW & ResEdit -> Symantec -> CodeWarrior -> XCode


    Geistesgegenwart schrieb:
    --------------------------------------------------------------------------------
    > Erst PowerPC, dann Intel, bald evntl. ARM. Und das ausgerechnet von Apple,
    > die doch mit ihrem Focus auf Obj-C ein so gar nicht bytecode orientiert
    > arbeiten. Dazu wird Java als "Deprecated" angesehen, darf also nicht im
    > Appstore vertrieben werden.
    >
    > Vielleicht sollte Apple seine Entwickler weg vom native binary bringen, hin
    > zu bytecode, IL oder JIT. Mit Java, C#, Python oder HTML5/JS. Oder aber ein
    > LLVM binärformat verwenden, das man als als standalone .app ausliefern
    > kann.



    1 mal bearbeitet, zuletzt am 06.11.12 10:21 durch MarioWario.

  5. Re: Ausgerechnet Apple springt zwischen den CPU Arches...

    Autor: KleinerWolf 06.11.12 - 10:39

    Du hast den Werbemüll von Apple auch geglaubt oder?
    Es war in vielen Programm definitiv mehr Arbeit, als nur ein "Häkchen" zu setzen.

  6. Re: Ausgerechnet Apple springt zwischen den CPU Arches...

    Autor: KleinerWolf 06.11.12 - 10:40

    > Haben auch nicht mit Objective C angefangen:
    > GNU C Compiler -> MPW & ResEdit -> Symantec -> CodeWarrior -> XCode

    Dreirad -> Auto -> Garage -> Haus

    oder wie?

  7. Re: Ausgerechnet Apple springt zwischen den CPU Arches...

    Autor: Geistesgegenwart 06.11.12 - 11:11

    gorsch schrieb:
    --------------------------------------------------------------------------------
    > Wo ist denn bitte der Vorteil Bytecode/VMs? Dass du ein paar MB für's
    > Applikationsbinary sparst? Ist doch Mumpitz!

    Der Vorteil: Der Entwickler einer 3rd Party-app brauch nicht neu zu kompilieren wenn Apple mal wieder die Arch switcht. Wenn du nämlich pech hast und die Software geschäftskritisch ist, aber nicht mehr Vertrieben wird, wird das nie passieren. Damit bist du gezwungen auf der alten Arch zu bleiben. Beim Bytecode muss nur Apple den JIT anpassen, und du kannst auf ner anderen Arch auch deine "alten" Anwendungen weiternutzen.

    > Zwei Binaries in ein .app zu packen hat schon beim PPC/x86 Switch gut
    > funktioniert.

    Benötigt aber pro-aktives rekompilieren jedes Entwicklers / jeder App. Das ist schlicht unrealistisch.

    > Abgesehen ist Apple schon heute einer der größten Nutzer und Mitentwickler
    > von LLVM - und was macht LLVM? Native Binaries ausspucken. Just-in-Time
    > oder Ahead-of-Time.

    Ja, aber es fehlt ein llvm-bytecode executable format, sodass ich nur den LLVM bytecode ausliefern msus als Entwickler, und das JIT findet dann automatisch beim client statt wenn der auf ne .App doppelklickt (quasi muss apple ein Mach-LLVM entwickeln und verwenden). Zugegeben, diesen letzten Punkt kann Apple recht schnell lösen.

  8. Re: Ausgerechnet Apple springt zwischen den CPU Arches...

    Autor: gorsch 06.11.12 - 11:36

    >Der Vorteil: Der Entwickler einer 3rd Party-app brauch nicht neu zu kompilieren wenn Apple mal wieder die Arch switcht. Wenn du nämlich pech hast und die Software geschäftskritisch ist, aber nicht mehr Vertrieben wird, wird das nie passieren. Damit bist du gezwungen auf der alten Arch zu bleiben. Beim Bytecode muss nur Apple den JIT anpassen, und du kannst auf ner anderen Arch auch deine "alten" Anwendungen weiternutzen.
    Also wenn du "geschäftkritische" Anwendungen benutzt, die nicht alle fünf Jahre (oder wie oft die Arch gewechselt wird) mal geupdatet werden, dann läuft *da* irgendwas falsch, aber garantiert nicht bei Apple. Sowas mag zwar durchaus mal vorkommen, aber eher nicht im Geschäftsbereich von Apple Computern. Für mich jedenfalls kein sonderlich starkes Argument.

    >Benötigt aber pro-aktives rekompilieren jedes Entwicklers / jeder App. Das ist schlicht unrealistisch.
    Das ist unrealistisch, dass der Entwickler mal seine Anwendung neu kompiliert? Wie gesagt, bei PPC/x86 hat es gut geklappt. Eine Anwendung, die vom Entwickler nichtmehr supported wird, will man ja auch nicht benutzen - insofern also kein großer Verlust.

    >Ja, aber es fehlt ein llvm-bytecode executable format, sodass ich nur den LLVM bytecode ausliefern msus als Entwickler, und das JIT findet dann automatisch beim client statt wenn der auf ne .App doppelklickt (quasi muss apple ein Mach-LLVM entwickeln und verwenden). Zugegeben, diesen letzten Punkt kann Apple recht schnell lösen.
    Ja, wie gesagt, braucht man nicht wirklich. Die relevanten Vorteile von LLVM/JIT nutzt Apple bereits heute.

  9. Re: Ausgerechnet Apple springt zwischen den CPU Arches...

    Autor: fool 06.11.12 - 12:14

    Nein, ich entwickel seit 68k-Zeiten Software für Mac OS.

  10. Re: Ausgerechnet Apple springt zwischen den CPU Arches...

    Autor: zonk 06.11.12 - 12:42

    dann hat da was bei den Programmen gehackt und nicht am Haeckchen ;)

  11. Re: Ausgerechnet Apple springt zwischen den CPU Arches...

    Autor: KleinerWolf 06.11.12 - 14:26

    ach fu. Haken, Haken, Haken!!!

  12. Re: Ausgerechnet Apple springt zwischen den CPU Arches...

    Autor: KleinerWolf 06.11.12 - 14:30

    Ich programmiere auch seit der 68k Zeit, nur andere Plattform. Wer hat nun recht?
    Ich meine 3 Zeilen zusammengeklickte Apps mit den Standard UI Styles waren wirklich per "Haken" auf Intel Binary übersetzbar.
    Und vermutlich wird das mit den iOS Programmen auch so sein, aber wir reden doch hier von richtigen Programmen oder? Also nicht von Spielzeug.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. STADT ERLANGEN, Erlangen
  2. Allianz Lebensversicherungs - AG, Stuttgart
  3. Bechtle AG, Bonn
  4. DE-CIX Management GmbH, Frankfurt am Main

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. (u. a. XCOM 2 Collection für 16,99€, Bioshock: The Collection für 11,99€, Mafia 3: The...
  2. (u. a. Elite Dangerous für 5,99€, Struggling für 7,25€, Planet Zoo für 21,99€, Planet...
  3. 31,99€
  4. 7,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Antivirus: Das Jahr der unsicheren Sicherheitssoftware
Antivirus
Das Jahr der unsicheren Sicherheitssoftware

Antivirus-Software soll uns eigentlich schützen, doch das vergangene Jahr hat erneut gezeigt: Statt Schutz gibt es Sicherheitsprobleme frei Haus.
Von Moritz Tremmel

  1. NortonLifeLock Norton kauft deutschen Antivirenhersteller Avira

Elektromobilität 2020/21: Nur Tesla legte in der Krise zu
Elektromobilität 2020/21
Nur Tesla legte in der Krise zu

Für die Autoindustrie war 2020 ein hartes Jahr. Wer im Homeoffice arbeitet und auch sonst zu Hause bleibt, braucht kein neues Auto. Doch in einem schwierigen Umfeld entwickelten sich die E-Auto-Verkäufe sehr gut.
Eine Analyse von Dirk Kunde

  1. Elektromobilität Akkupreise fallen auf Rekord von 66 Euro/kWh
  2. Transporter Mercedes eSprinter bekommt neue Elektroplattform
  3. Aptera Günstige Elektrofahrzeuge vorbestellbar

Notebook-Displays: Tschüss 16:9, hallo 16:10!
Notebook-Displays
Tschüss 16:9, hallo 16:10!

Endlich schwenken die Laptop-Hersteller auf Displays mit mehr Pixeln in der Vertikalen um. Das war überfällig - ist aber noch nicht genug.
Ein IMHO von Marc Sauter

  1. Microsoft LTE-Laptops für Schüler kosten 200 US-Dollar
  2. Galaxy Book Flex2 5G Samsungs Notebook unterstützt S-Pen und 5G
  3. Expertbook B9 (B9400) Ultrabook von Asus nutzt Tiger Lake und Thunderbolt 4