News Erste Informationen zur neuen „ARMv8“-Architektur

[FlashBurn]

aber es gibt Software, die eben nicht als Source vorliegt sondern prinzipiell als Binary damit man den Source nicht einsehen kann (außer man betreibt Reverse Engineering) - zB Skype.

Richtig, aber wie gesagt, reden wir hier von Android und da ist das meiste in Java geschrieben oder muss (zwecks FPU) in mehreren Varianten vorliegen. Der Source von Skype liegt aber Skype vor und die gibt es noch Auch wurde Skype ja erst auf ARM portiert, sprich es musste eh schonmal vor kurzer Zeit gemacht werden. Genauso wird Skype auch auf dem neuem Ubuntu (12.04) zwecks FPU nicht mehr laufen und man braucht es eh neu.

Jetzt muss man solche Leute dazu kriegen die Software auf die neue Architektur zu portieren und wenn was nicht läuft, wer kümmert sich dann darum?

Das sehe ich so, dass ist Skype´s Problem Das war es vorher auch, ansonsten siehe oben.

Aber die Biester werden nicht nur da eingesetzt. Im Gegenteil, bei eingebetteten Systemen im Allgemeinen reden wir von ein paar zig Milliarden Stück pro Jahr.
Und da kann es durchaus extrem teure Spezialsoftware geben, z.B. in den Bereichen Automotive, Military usw. Wenn man diesen Leuten die Portierung erschwert, verliert man sie u.U. als Kunden. Wer will das schon? :-)

Deswegen sagte ich ja auch, dass auf Embedded Systems eh kein 64bit nötig ist und die Software auch nicht portiert werden muss. Sobald es nötig ist muss die Software eh portiert werden.
Es wird immer 32bit ARM MikroController geben, von daher sehe ich das nicht als Problem.

 

[Knuddelbearli]

dachte aktuelle ARM CPUs ahben bereits eine 40 bit unterstüzung ?!?

 

[FlashBurn]

dachte aktuelle ARM CPUs ahben bereits eine 40 bit unterstüzung ?!?

Nope, wimre erst ab Cortex-A15 und auch dann nur in Form von PAE, sprich 32bit und damit immer nur max 4GB pro Prozess, aber mehr für das ganze System.

 

[DUNnet]

Warum kann man beim Aufstieg von 32bit auf 64bit keinen klaren Schnitt machen?

Immer schleppt man bei 64bit diesen 32bit Ballast mit ... würde die Chips doch weniger kompliziert machen. Man müsste nur einmal konsequent sein.

Oder gibt's noch andere Gründe ?

Man benötigt Abwärtskompatibilität der Befehlssätze,
8/16 Bit Anwendungen kannst Du mit deinem akutellen Win7 x64 auch nicht mehr nutzen,
fällt Dir was auf ?

 

[FlashBurn]

Man benötigt Abwärtskompatibilität der Befehlssätze

Wofür?

8/16 Bit Anwendungen kannst Du mit deinem akutellen Win7 x64 auch nicht mehr nutzen

Also erstens geht das auch mit Win7 x64 noch (Emulator ) und zweitens ist das ne komische Aussage. Denn es geht darum das es die CPUs können, das OS interessiert da nicht. Ich kann auch auf x64 nen OS laufen lassen das nur x64 Programme unterstützt, ändert aber nix daran das die CPU auch noch 16bit kann.

 

[Plastikman]

Entwicklung geht nicht von heute auf morgen 8[

kann ich nur zustimmen. Jetzt, wo ich auf der Seite von Entwicklung stehe, verstehe ich es so langsam. Die meisten wissen einfach nicht wieviel Arbeit in so etwas steckt.!

 

[KainerM]

Traurig, dass der Horizont der Meisten User hier nicht über Smartphone rausgeht. Der Smartphonemarkt ist ein relativ kleiner. Da reden wir ja nur von ein paar hundert Millionen Geräten. Bei embedded Systems oder primitivanwendungen reden wir von Milliarden bei den Stückzahlen.

Was ich mich aber frage ist was man mit Partnern, die bereits einen Compiler besitzen, an der Architektur entwickeln will. Den compiler braucht man später, nicht wenn man die Architektur auslegt, schon garnicht zu einer so einem frühen Zeitpunkt.

Und die News an sich hat halt wenig Aussagekraft, weil es wird sich was ändern, es werden aber auch sachen gleich bleiben. Toll. Ich hab ein Geheimniss für euch:BMW arbeitet an einem neuen Auto, und das kommt in frühestens drei Jahren auf den Markt.

Mfg

mfg

 

[Yamazaki]

Den Grund bekam Intel mit ihrem 80286 zu spüren, keine hielt es für nötig 32Bit zu haben weil es garnicht soviel RAM gab...

Wohl eher 80386, der 80286 ist ein 16bit-Prozessor.

 

[BOBderBAGGER]

Bei embedded Systems oder primitivanwendungen reden wir von Milliarden bei den Stückzahlen.

gerade primitiv anwendungen fallen da wohl komplett raus. da laufen dann eher Mikrocontroller drin

 

[CHAOSMAYHEMSOAP]

das militär in den usa hat vorrang ^^

Das Militär setzt eher auf PowerPC (z.B. RAD6000, RAD750)

Zugegeben, für Mobiltelefone gehen die einen oder anderen hundert Millionen verschiedener ARM-Prozessoren / Jahr drauf.

In der Presseerklärung zu den Q3/2011 Geschäftszahlen gibt ARM die Anzahl der ausgelieferten ARM CPUs mit 1,9 Milliarden an. Davon 1 Mrd. im Handy/Mobile Computing Bereich und 0,9 Mrd. in Form von embedded od. consumer digital devices.

gerade primitiv anwendungen fallen da wohl komplett raus. da laufen dann eher Mikrocontroller drin

Und in diesen Mikrocontrollen steckt auch ein ARM Kern. Allerdings ein Cortex-R od. -M und kein Cortex-A.

 

[FlashBurn]

Und in diesen Mikrocontrollen steckt auch ein ARM Kern. Allerdings ein Cortex-R od. -M und kein Cortex-A.

Mein Reden. Wieso also den alten Kram mitschleppen, wenn man ja auch genug 32bit CPUs im Angebot hat?

 

[mdave]

In der Presseerklärung zu den Q3/2011 Geschäftszahlen gibt ARM die Anzahl der ausgelieferten ARM CPUs mit 1,9 Milliarden an. Davon 1 Mrd. im Handy/Mobile Computing Bereich und 0,9 Mrd. in Form von embedded od. consumer digital devices.

Ah, interessant, danke!
Wobei man natürlich sagen muss, dass mobile computing bei Weitem nicht nur aus Mobiltelefonen besteht. Aber die Tendenz ist erkennbar, denke ich.
Ich hätte allerdings erwartet, dass ARM sich mittlerweile etwas mehr in anderen Sparten wie automotive gegen Renesas & Co durgesetzt hat und da größere Stückzahlen los wird.
Naja, kommt noch. :-)

Und in diesen Mikrocontrollen steckt auch ein ARM Kern. Allerdings ein Cortex-R od. -M und kein Cortex-A.

Auch, ja. Wobei da aber (gerade eben noch) 8-bit Controller dominant sind.

Grüße,
David