Weiß das jemand, warum man x86 CPUs nur als große dicke Mikroprozessoren
kriegt, aber vom recht teuren Intel Edison mal abgesehen, nirgends als
SoC für wenig Geld für Mikrocontrolleraufgaben?
Man könnte doch davon ausgehen, dass man zumindest irgendwas Atom oder
386er mäßiges als SoC kriegen könnte.
Genauso haben ja auch noch AMD, IBM und Cyrix eine x86 Lizenz, die
stellen aber auch nichts entsprechendes her.
x86 CPUs sind immer noch in einer Domäne von echten PCs, während ARM
sowohl als SoC Mikrocontroller und SoC Mikropozessoren, also als PC
Ersatz, Zuhause ist.
Im Prinzip gibt es x86-"SOC"s; einerseits in Form des schon sehr arg
angestaubten 80188/186, andererseits von Intel unter den Namen "Quark":
http://www.intel.de/content/www/de/de/embedded/products/quark/overview.html
Aber ... wo liegt da der Witz?
Anders als bei einem "richtigen" Atom, der mit passender Umgebung
PC-kompatible Hardware ermöglicht (wie z.B. der "Lattepanda") sind hier
die Einschränkungen so groß, daß man Software sehr speziell anpassen
muss. Und da ist dann der "Vorteil" der x86-Architektur weitestgehend
irrelevant.
Rufus Τ. F. schrieb:> Im Prinzip gibt es x86-"SOC"s; einerseits in Form des schon sehr> arg> angestaubten 80188/186, andererseits von Intel unter den Namen "Quark":>> http://www.intel.de/content/www/de/de/embedded/pro...
Cool, den Intel Quark kannte ich noch nicht.
Laut WP entspricht er dem Pentium Befehlssatz mit ein paar
Erweiterungen, dazu auch die Sparmodi der Atom Reihe.
Also in etwa das, was ich mir so vorgestellt habe bzw. gefragt habe,
warum ich da in dieser Richtung nichts gefunden habe.
> Aber ... wo liegt da der Witz?>> Anders als bei einem "richtigen" Atom, der mit passender Umgebung> PC-kompatible Hardware ermöglicht (wie z.B. der "Lattepanda") sind hier> die Einschränkungen so groß, daß man Software sehr speziell anpassen> muss. Und da ist dann der "Vorteil" der x86-Architektur weitestgehend> irrelevant.
Nun, der Vorteil läge im Know How der Softwareentwickler.
Den x86 Befehlssatz kennt jeder, bei ARM wäre ich mir da nicht so
sicher.
Die Compiler sind ebenfalls hochoptimiert.
Testen kann man den Code auf echter HW auf einem normalen PC.
Das sind durchaus Vorteile.
Allerdings scheint er recht teuer zu sein, im Vergleich zu ARM.
Bei Mouser 1 Stück ca. 10 €.
x86 schrieb:> Nun, der Vorteil läge im Know How der Softwareentwickler.
Welcher PC-Software-Entwickler kennt denn noch die x86 Assembly, oder
weiß überhaupt was das ist? Und Embedded-Entwickler kennen
wahrscheinlich ARM besser als x86. Die größte Lernkurve besteht doch eh
in der Peripherie-Ansteuerung, mit dem Befehlssatz befasst sich doch der
Compiler. Die, die tatsächlich taktgenaue Assembly-Optimierung
betreiben, lassen sich von der einfacheren (als x86) ARM-Assembly auch
nicht schocken.
x86 schrieb:> Die Compiler sind ebenfalls hochoptimiert.
Und ARM-Compiler nicht? Die Architektur gibts ja auch nicht erst seit
gestern.
x86 schrieb:> Testen kann man den Code auf echter HW auf einem normalen PC.
Nur dass einem da die ganze Peripherie fehlt, welche das Embedded System
ja überhaupt ausmacht. Sonst bräuchte man ja keinen SoC.
x86 schrieb:> Allerdings scheint er recht teuer zu sein, im Vergleich zu ARM.
Ja, weil x86 ineffizienter (Chipfläche, Stromverbrauch) und teurer ist,
und weil ARM-Controller aufgrund der höheren Flexibilität in viel
höheren Stückzahlen hergestellt werden...
Rufus Τ. F. schrieb:> x86 schrieb:>> Die Compiler sind ebenfalls hochoptimiert.>> Du kannst davon ausgehen, daß das auf ARM-Compiler ebenso zutrifft.
Auch für C++ und andere Sprachen?
Natürlich gibt es auch hochoptimierte C Compiler für ARM, aber die
Erfahrung in Mannjahre dürfte da kleiner sein.
Dr. Sommer schrieb:> x86 schrieb:>> Nun, der Vorteil läge im Know How der Softwareentwickler.>> Welcher PC-Software-Entwickler kennt denn noch die x86 Assembly, oder> weiß überhaupt was das ist?
Jeder, der in C oder C++ entwickelt.
JavaScript, C#, Python, PHP und Java Kiddis mal ausgenommen.
Aber für C und C++ macht es schon Sinn zu sehen, was der Compiler aus
dem Code macht.
Dafür gibt es dann die Ausgabe als Assembler, die jeder gute C und C++
Compiler kann und wer die lesen will, der lernt natürlich x86 Assembler.
> Und Embedded-Entwickler kennen> wahrscheinlich ARM besser als x86.
Die, ja.
Bei den reinen Softwareentwicklern und Informatikern die nicht so viel
mit Embedded machen, sieht das aber wieder anders aus.
>> x86 schrieb:>> Die Compiler sind ebenfalls hochoptimiert.> Und ARM-Compiler nicht?
Das habe ich nicht gesagt.
> Die Architektur gibts ja auch nicht erst seit> gestern.
Das mag sein, aber die Verbreitung der x86 war auch schon vor
Jahrzehnten wesentlich größer als bei ARM.
Und die Verbreitung hat dann auch Auswirkung auf die
Compilerentwicklung.
>> x86 schrieb:>> Testen kann man den Code auf echter HW auf einem normalen PC.> Nur dass einem da die ganze Peripherie fehlt, welche das Embedded System> ja überhaupt ausmacht. Sonst bräuchte man ja keinen SoC.
Schon klar.
>> x86 schrieb:>> Allerdings scheint er recht teuer zu sein, im Vergleich zu ARM.> Ja, weil x86 ineffizienter (Chipfläche, Stromverbrauch) und teurer ist,> und weil ARM-Controller aufgrund der höheren Flexibilität in viel> höheren Stückzahlen hergestellt werden...
Intel ist dafür führend bei kleineren Fertigungstechniken, das könnte
das durchaus relativieren.
Ein Pentium ist außerdem bereits RISC Technik.
x86 schrieb:> Auch für C++ und andere Sprachen?
Logischerweise, denn bei den meisten Compilern laufen sowohl C als auch
C++ durch die gleichen Optimierungs-Algorithmen.
x86 schrieb:> Natürlich gibt es auch hochoptimierte C Compiler für ARM, aber die> Erfahrung in Mannjahre dürfte da kleiner sein.
Für ARM-Controller braucht man auch gar nicht so stark optimieren, weil
die u.a. wegen einfacher Pipelines und mangels Cache nicht so viele
Tricks brauchen...
x86 schrieb:> Jeder, der in C oder C++ entwickelt.
Das tun a) nur sehr wenige und b) sehe ich auch wenig Grund, warum man
als C(++) -Entwickler Assembly können müsste. Wer schaut sich ernsthaft
die Disassembly seines Programms an? Höchstens bei einigen sehr
begrenzten extrem performance-kritischen Teilen, aber wie oft kommt das
vor...
x86 schrieb:> JavaScript, C#, Python, PHP und Java Kiddis mal ausgenommen.
Ah, der allergrößte, und am meisten Umsatz generierende Teil der
Programmierer sind also Kiddies. So kann man sich auch seine Welt
zurechtbiegen ;-) Vergleiche mal die Ökosysteme von Java und C++...
x86 schrieb:> Bei den reinen Softwareentwicklern und Informatikern die nicht so viel> mit Embedded machen, sieht das aber wieder anders aus.
Und wer nicht in Embedded arbeitet, brauch SoC's, weil...?
x86 schrieb:> Das mag sein, aber die Verbreitung der x86 war auch schon vor> Jahrzehnten wesentlich größer als bei ARM.
Sicher? Ich habe 1 PC mit x86-Prozessor, und bestimmt 10 Geräte mit
ARM-Prozessor/Mikrocontroller...
x86 schrieb:> Intel ist dafür führend bei kleineren Fertigungstechniken, das könnte> das durchaus relativieren.
Das stimmt, aber teurer wirds deswegen trotzdem.
x86 schrieb:> Ein Pentium ist außerdem bereits RISC Technik.
Der Kern schon, aber den Decoder brauchts trotzdem (-> Chipfläche!).
x86 schrieb:> Auch für C++ und andere Sprachen?
Ja, natürlich auch für C++ und natürlich auch andere Sprachen. GCC oder
Clang unterstützen die ARM-Architektur schon länger und gerade bei
letzterem wird klar wie egal eigentlich die Architektur ist. Alles wird
zunächst in eine LLVM-IR übersetzt (gewissermaßen plattformunabhängiger
high-level Assembler; IR: intermediate representation) und dann mittels
eines entsprechenden Backends für die jeweilige Architektur assembliert.
Da ist es dann relativ egal ob da ein LLVM-Backend für AVR, Cortex-M,
Cortex-A oder x86 hinten dran hängt. Die Optimierungen finden
(weitestgehend) vorher statt. Sicherlich mag ein Intel-Compiler für x86
nochmal 5% performanteren Code erzeugen aber abgesehen von irgendwelchen
HPC-Anwendungen interessiert das doch keinen Mensch.
Dr. Sommer schrieb:> x86 schrieb:>> Das mag sein, aber die Verbreitung der x86 war auch schon vor>> Jahrzehnten wesentlich größer als bei ARM.> Sicher? Ich habe 1 PC mit x86-Prozessor, und bestimmt 10 Geräte mit> ARM-Prozessor/Mikrocontroller...
Ja, da bin ich mir sicher.
Einen Acorn Archimedes hatten nämlich damals die wenigstens, während x86
CPUs neben den Amigas, Ataris und Macs Standard waren, ab etwa 1990-1992
übernahmen dann die x86 gänzlich die Führung.
Und zu der Zeit war ARM Technik im µC Bereich noch gar nicht wirklich
angekommen, das geschah alles erst viel später.
6502, 8008, 8080, Z80, 68k und PIC10 waren da schneller und früher
vertreten.
Kann natürlich auch sein, dass du da noch nicht auf der Welt warst.
>> x86 schrieb:>> Ein Pentium ist außerdem bereits RISC Technik.> Der Kern schon, aber den Decoder brauchts trotzdem (-> Chipfläche!).
Die Chipfläche wird durch die kleinere Fertigungstechnik kompensiert.
Der Preis kann höher sein, wobei ich aber auch davon ausgehe, dass sich
die Fabriken, die diese Intel SOC CPUs fertigen sich bereits schon
vorher durch die normalen Intel CPUs amortisiert haben.
Der Quark wird nämlich bei etwa 32 nm gefertigt, die Fabriken, die das
machen dürften, fertigten aber schon vor Jahren Sandy Briges in 32 nm
Technik, die Fabrik dürfte also abbezahlt sein.
Christopher J. schrieb:> Da ist es dann relativ egal ob da ein LLVM-Backend für AVR, Cortex-M,> Cortex-A oder x86 hinten dran hängt. Die Optimierungen finden> (weitestgehend) vorher statt.
Naja, weitestgehend ist ein relativer Begriff.
C++ ist natürlich eine Hochkomplexe Sprache, aber der Intel x86
Befehlssatz ist das auch. Da sind noch genug Optimierungsmöglichkeiten
im Backend möglich.
In einem PC ist ein einzelner x86, wenn man die Cores nicht separat
rechnet.
Aber wenn man zählt, was alles drum im PC an Controllern steckt... Schon
dem Original-PC stand ein 8048 in der Tastatur zur Seite. Ab AT wars
dann ein ähnlicher Kollege am anderen Ende des Tastaturkabels. Mit
Festplatte kam dann vielleicht ein 8085 oder Z8 auf dem Disk-Controller
dazu, und noch irgendeiner auf der Platte selbst - da allerdings waren
188/186er einstmals recht beliebt.
Heute ist nicht einmal die Intel-CPU selbst auf sich allein gestellt,
sondern hat einen Controller mit auf dem Die, der drauf achtet, dass sie
sich wohlfühlt.
Wenn man den ganzen Kram zusammenrechnet, mitsamt Drucker, Router und
wasweissich, dann kommt ein Haufen Kram zusammen, von dem allenfalls
noch die SAN-Box von einem Intel-Atom angetrieben wird. Der Rest
verwendet einige 8- und 16-Bitter und sonst wohl hauptsächlich ARM und
MIPS.
Gründe:
- Neu rauskommende x86er werden jeweils mit teuerster Fertigungstechnik
hergestellt, und deren Grösse orientiert sich an dem, was für den
PC-Markt ökonomisch machbar ist. Metallisierungs-Layer was die Technik
hergibt, kleinste Strukturen, etc. Wenn diese Designs alt werden, dann
werden sie sie in der Fertigung zwar billiger, bleiben aber teurer als
jene Chips, die von vorneherein für billigere Fertigung entworfen
werden.
- ARMs kamen sehr früh als Cores für Custom-Chips raus. Der Rest der
Welt baute eigenständige Prozessoren am oberen Rand der erzielbaren
Performance. ARM hingegen bot Layouts und Verilog/VHDL-Komponenten, die
viel weniger Platz beanspruchten. Aus denen die Kunden sich ihre SoCs
selber stricken konnten. Bei den 32-Bittern waren sie damals anfangs
wohl ziemlich allein auf dem Markt. Dann kamen die Handies und 16-Bitter
kamen ans Ende ihrer Architektur. ARM war da.
- Man kann x86 natürlich auch für den SoC-Markt bauen. Aber wenn man
damit die Konkurrenz zu den Cortex-A sucht, dann kämpft man nicht als
Marktführer gegen Konkurrenten, sondern als Neuling gegen den
Marktführer. Da ist pro Stück nur wenig Geld drin, aber viel
Support-Aufwand. Wenn man andererseits den Cortex-M Konkurrenz machen
will, dann hat man den Nachteil einer komplexeren und damit teureren
Architektur.
- Assembler-Programmierung ist bei 32-Bittern nicht direkt en vogue,
ausser in raren Spezialfällen. Kompatibilität mit in Jahrzehnten
gewachsener alter Software interessiert kein Schwein. Warum also x86?
Bloss weil ältere Semester die Mnemonics von anno 386 noch auswendig
kennen? Der Compiler kennt sie auch und das reicht. Die x86-Mnemonics
heutiger Highends kriegt ohnehin nur noch ein Idiot Savant noch komplett
ins Hirn.
x86 schrieb:> Nun, der Vorteil läge im Know How der Softwareentwickler.> Den x86 Befehlssatz kennt jeder
Ich kenn kaum einen Softwareentwickler der den x86 Befehlssatz kennt
oder sich auch nur dafür interessiert. 99.9999% der Leute programmieren
in Hochsprachen. Einen C-Programmierer interessierts vielleicht noch ob
die Maschine 64 Bit hat oder nur 32 oder wie die Endianness ist aber das
wars dann auch schon.
A. K. schrieb:> - Assembler-Programmierung ist bei 32-Bittern nicht direkt en vogue,> ausser in raren Spezialfällen. Kompatibilität mit in Jahrzehnten> gewachsener alter Software interessiert kein Schwein. Warum also x86?
Smartphones, auf denen (proprietäre) Windows oder Linux-Programme
laufen, wären schon eine feine Sache. Microsoft versucht zwar in die
Richtung zu gehen, wenn ich das richtig verstanden habe allerdings mit
"Apps", die auf dem PC laufen und nicht mit PC-Programmen, welche auch
auf dem Handy laufen. Also doch wieder eine Murks-Lösung.
Feldstecher schrieb:> Smartphones, auf denen (proprietäre) Windows oder Linux-Programme> laufen, wären schon eine feine Sache.
Steinalten MSDOS-Programmen bin ich in Android schon begegnet. Ohne
separate Tastatur ist das allerdings eine Katastrophe.
A. K. schrieb:> Steinalten MSDOS-Programmen bin ich in Android schon begegnet. Ohne> separate Tastatur ist das allerdings eine Katastrophe.
Naja, MSDOS-Programme sind auch ein Extrembeispiel. In der Nach-DOS-Ära
hat sich darstellungsmäßig noch viel getan.
Auf Tablets beispielsweise ließen sich PC-Programme von der Auflösung
her gut unterbringen. Von der Seite der Programmierung aus betrachtet
wäre es sicherlich auch sinnvoll, nicht zig unterschiedliche
Hardware-Plattformen zu haben. Ich vermute aber, dass es einfach eine
Preisfrage ist. 1 GHz auf x86 sind halt noch was anderes wie 1 GHz ARM.
Und die (teure) Leistung wird eben als SOC nicht benötigt.
Feldstecher schrieb:> Smartphones, auf denen (proprietäre) Windows oder Linux-Programme> laufen, wären schon eine feine Sache.
Dafür gibts die Tablets mit Intel Atom.
Bernd K. schrieb:> x86 schrieb:>> Nun, der Vorteil läge im Know How der Softwareentwickler.>> Den x86 Befehlssatz kennt jeder>> Ich kenn kaum einen Softwareentwickler der den x86 Befehlssatz kennt> oder sich auch nur dafür interessiert.
Im Diplom Informatikstudium war Assemblerprogrammierung ein Fach das
Bestandteil des Studiums war.
Vielleicht ist es im Bachelor weggefallen, aber in C müssen die in
einigen Fächern auch noch programmieren.
> 99.9999% der Leute programmieren> in Hochsprachen. Einen C-Programmierer interessierts vielleicht noch ob> die Maschine 64 Bit hat oder nur 32 oder wie die Endianness ist aber das> wars dann auch schon.
Das gilt auch für die C++ Progammierer.
Und wie ich bereits sagte, wenn man Performance benötigt, dann guckt man
sich den Assemblercode an, den der Compiler produziert.
Feldstecher schrieb:> A. K. schrieb:>> - Assembler-Programmierung ist bei 32-Bittern nicht direkt en vogue,>> ausser in raren Spezialfällen. Kompatibilität mit in Jahrzehnten>> gewachsener alter Software interessiert kein Schwein. Warum also x86?> Smartphones, auf denen (proprietäre) Windows oder Linux-Programme> laufen, wären schon eine feine Sache. Microsoft versucht zwar in die> Richtung zu gehen, wenn ich das richtig verstanden habe allerdings mit> "Apps", die auf dem PC laufen und nicht mit PC-Programmen, welche auch> auf dem Handy laufen. Also doch wieder eine Murks-Lösung.
Microsoft macht das gleiche, was Google macht, nur nehmen die C# anstatt
Java und das läuft natürlich auf einem Runtime Environment.
In Android eine androidisierte JVM und in Windows 10 Mobile eine .Net
Umgebung.
Die Apps Sache hat nur was mit den verwendeten Bibliotheken zu tun, die
von der Usability her Smartphone tauglich sind.
Das OS selbst und wichtige Systemkomponenten, wie eben die .Net Umgebung
läuft nativ.
Feldstecher schrieb:> 1 GHz auf x86 sind halt noch was anderes wie 1 GHz ARM.> Und die (teure) Leistung wird eben als SOC nicht benötigt.
Also mit den modernsten ARM SoCs würde ich das nicht unbedingt so sehen.
Klar mit den neuesten high-end Intel CPUs können die nicht mithalten
aber das ist auch egal - ich arbeite auch noch mit PCs mit ca. 5 Jahre
alten Intel CPUs (und zwar nicht die high-end Varianten sondern normale)
und bin zufrieden damit ;-)
Heutige ARMs können da durchaus mithalten was die gefühlte Performance
anbelangt.
Der Vergleich gelingt aber nur mit Linux (man kann ein vollwertiges
Ubuntu Linux drauf laufen lassen) - Windows ist halt schwierig.
Was oft einschränkt sind die Datenträger - da hat man i.d.R. halt keine
schnelle PCIe/SATA SSD sondern nur irgendwas ala eMMC, das ist halt
lahm, das liegt aber nicht an der CPU.
Zum Optimieren: Was vor 20 Jahren für x86 optimiert wurde macht doch
heute keinen Unterschied mehr für ARM - solche Optimierungen sind heute
standard in allen guten Compilern...
x86 schrieb:> Bernd K. schrieb:>> x86 schrieb:>>> Nun, der Vorteil läge im Know How der Softwareentwickler.>>> Den x86 Befehlssatz kennt jeder>>>> Ich kenn kaum einen Softwareentwickler der den x86 Befehlssatz kennt>> oder sich auch nur dafür interessiert.>> Im Diplom Informatikstudium war Assemblerprogrammierung ein Fach das> Bestandteil des Studiums war.>> Vielleicht ist es im Bachelor weggefallen, aber in C müssen die in> einigen Fächern auch noch programmieren.
Heutzutage machen die meisten Studenten Java, die wenigsten vielleicht
noch C, aber Assembler? Mit Assembler kommt man höchstens in Fächer wie
Rechnerarchitektur oder Mikrocomputertechnik in Berührung, richtige
Kenntnisse erlernt man dort nicht. Außerdem werden die Fächer meiner
Erfahrung nach gerne gemieden, weil LowLevel die Wenigsten interessiert.
x86 schrieb:> Und wie ich bereits sagte, wenn man Performance benötigt, dann guckt man> sich den Assemblercode an, den der Compiler produziert.
Eigentlich sieht man sich erst mal nach einem besseren
Algorithmus/Softwarearchitektur um, denn das Optimierungspotential ist
dort wesentlich höher. Bei einem schlechten Algorithmus hilft auch der
beste Maschinencode nichts.
Feldstecher schrieb:> Smartphones, auf denen (proprietäre) Windows oder Linux-Programme> laufen, wären schon eine feine Sache.
Es gab Ubuntu für Smartphones. Wurde vor wenigen Tagen eingestellt.
Mac G. schrieb:> Zum Optimieren: Was vor 20 Jahren für x86 optimiert wurde macht doch> heute keinen Unterschied mehr für ARM - solche Optimierungen sind heute> standard in allen guten Compilern...
Man sollte vor allem für den richtigen Prozessor kompilieren um
Hardwarebeschleunigung und Befehlssatzerweiterungen maximal nutzen zu
können. Machen aber leider nur die wenigsten.
Heute gibts immer noch Programme, die
x86 schrieb:> Und wie ich bereits sagte, wenn man Performance benötigt, dann guckt man> sich den Assemblercode an, den der Compiler produziert.
Und versteht dabei...
...gar nichts!
Besonders übersichtlich wird der Assemblercode nämlich nicht, wenn alle
Hardwarebeschleunigungen genutzt werden. Besonders übersichtlich wird
es, wenn man zusätzlich noch OpenCL zur Parallelisiserung nutzt.
Was da rauskommt, versteht kein normaler Mensch und den Befehlssatz von
der Grafikkarte versteht erst recht keiner.
x86 schrieb:> Nun, der Vorteil läge im Know How der Softwareentwickler.> Den x86 Befehlssatz kennt jeder, bei ARM wäre ich mir da nicht so> sicher.> Die Compiler sind ebenfalls hochoptimiert.
Es ist sehr viel schwieriger, für x86 wirklich guten Code zu erzeugen
als für ARM, MIPS oder PPC oder zB 68k. Letztere haben relativ viele
Register, und die Register funktionieren alle gleich. Jede Operation
geht mit jedem Register, der Befehlssatz ist "orthogonal"(†). Für die
automatische Codegenerierung und Optimierung ist das optimal.
Bei x86 haben viele Register Sonderfunktionen. AX ist der Akkumulator,
CX der Schleifenzähler, SI und DI werden für Blockoperationen gebraucht,
DX wird für die IO-Adresse einer IN oder OUT Operation gebraucht usw
usw. Mit so etwas tut sich ein Compiler deutlich schwerer.
X86 schleppt auch extrem viel Ballast mit sich. Der 16 Bit Protected
Mode und die Segmentierung werden heute eigentlich nicht mehr gebraucht,
belasten aber immer noch das Gesamtsystem. Was meinst Du, wie lange der
Wechsel in einen Interrupt oder der Aufruf eines Call Gates braucht. Das
sind viele 1000 Zyklen, weil alles mögliche an Segmentcaches
weggeschrieben und wieder neu geladen werden muss. Für Embedded-Zeugs
ist das ziemlich hinderlich. Bei ARM sind das so in der Größenordnung 20
Zyklen oder so (abhängig von der Architektur), einfach mal zum
Vergleich.
Und diesen Ballast bezahlst Du mit.
fchk
(†) Natürlich gibts hier und da ein paar Fußnoten, aber im großen und
ganzen stimmt das so.
x86 schrieb:> Feldstecher schrieb:>> Microsoft versucht zwar in die>> Richtung zu gehen, wenn ich das richtig verstanden habe allerdings mit>> "Apps", die auf dem PC laufen und nicht mit PC-Programmen, welche auch>> auf dem Handy laufen. Also doch wieder eine Murks-Lösung.> Microsoft macht das gleiche, was Google macht, nur nehmen die C# anstatt> Java und das läuft natürlich auf einem Runtime Environment.
Deswegen ja "Murks". Positiv finde ich den Ansatz, dass man ein Handy
durch Anschließen an einen Bildschirm in einen PC verwandeln kann. Da
aber doch nur "Apps" laufen, ist es für mich uninteressant.
Ich seh grad, dass es Tablets mit Atom-Prozessor schon für 100 Euro
gibt. Ein Smartphone mit echtem Windows wäre finanziell also wohl
genauso machbar. Kann der Energieverbrauch dagegen sprechen?
Frank K. schrieb:> Es ist sehr viel schwieriger, für x86 wirklich guten Code zu erzeugen> als für ARM, MIPS oder PPC oder zB 68k.
Mit amd64 ist man aus dem Gröbsten raus. Leidlich genug Register, und
die weitgehend orthogonal. Davor sind es einfach zu wenige.
> Bei x86 haben viele Register Sonderfunktionen. AX ist der Akkumulator,> CX der Schleifenzähler, SI und DI werden für Blockoperationen gebraucht,> DX wird für die IO-Adresse einer IN oder OUT Operation gebraucht usw> usw. Mit so etwas tut sich ein Compiler deutlich schwerer.
Schaurig ist eher die Trennung in wort- und byteadressierbare Register.
AH,CH,... sind für C völlig unnötig und in der Implementierung
heutzutage bloss ein Klotz am Bein, aber dafür kriegst du kein Byte in
SI. Auch hier hat amd64 aufgeräumt.
Die meisten Befehle sind abgesehen davon dann doch orthogonal. Von der
Häufigkeit her ist das vor allem bei (I)DIV und dynamischen Shifts
praktisch relevant. Und bei I/Os, wenn die oft vorkommen, aber das wär
bloss bei lowlevel µCs der Fall, wenn deren Konstruktuer zu doof war, um
es speicheradressiert zu implementieren.
> X86 schleppt auch extrem viel Ballast mit sich. Der 16 Bit Protected> Mode und die Segmentierung werden heute eigentlich nicht mehr gebraucht,> belasten aber immer noch das Gesamtsystem.
Es gab mal für embedded einen 386SX ohne real mode als 376, und später
einen 386EX speziell für embedded.
Die Segmentierung wird heute noch verwendet, allerdings nur noch
rudimentär. Thread local storage wird darüber implementiert. In der
Implementierung gibts dann auch einen Straftakt für die komplexere
Adressrechnung.
> Was meinst Du, wie lange der> Wechsel in einen Interrupt oder der Aufruf eines Call Gates braucht.
So weit ich weiss haben Betriebssysteme die volle Segmentierung mit Task
State Segments und allem Gedöns möglichst vermieden. Vielleicht gabs
eins für den Triple Fault, da ist das praktisch und die Performance
egal. Call Gates allein sind zwar langsamer als nötig, aber keine 1000
Takte schwer.
> Bei ARM sind das so in der Größenordnung 20> Zyklen oder so (abhängig von der Architektur), einfach mal zum> Vergleich.
Wobei ARMs Interrupt-Konzept auch ein Griff ins Klo war, wenngleich
nicht so tief, wenn die priorisiert sein sollten. Und was man hat, das
hat man (an der Backe). Erst mit der Abkehr von der nativen Architektur,
mit den Cortex M, sieht das wirklich besser aus.
Feldstecher schrieb:> Ich seh grad, dass es Tablets mit Atom-Prozessor schon für 100 Euro> gibt. Ein Smartphone mit echtem Windows wäre finanziell also wohl> genauso machbar. Kann der Energieverbrauch dagegen sprechen?
Ja. Windows und Windows-Software brauchen viel Rechenleistung,
Rechenleistung braucht Strom und Strom gibt Abwärme.
Das verträgt sich nur begrenzt mit einem kleinen Smartphon und gibt
sicher keine brauchbare Akkulaufzeit.
Frank K. schrieb:> Bei x86 haben viele Register Sonderfunktionen. AX ist der Akkumulator,> CX der Schleifenzähler, SI und DI werden für Blockoperationen gebraucht,> DX wird für die IO-Adresse einer IN oder OUT Operation gebraucht usw> usw. Mit so etwas tut sich ein Compiler deutlich schwerer.
Bei IA-32 sind die meisten Register General Purpose Register, also
wesentlich vielseitiger einsetzbar, als beim 8086 oder 80286.
Mit dem x86-64 kommt noch ein Dutzend weiterer Register hinzu.
Ich finde die Annahme unlogisch, dass x86 Compiler besser seien, weile
es die x86 Architektur schon lange gibt.
Denn das, was Intel vor 20-30 Jahren produzierte, ist mit den heutigen
Chips nicht mehr vergleichbar. Das Know-How, mit dem ich damals 186er
und 286er in Assembler programmierte ist heute fast vollkommen wertlos.
Die heutigen Intel Prozessoren haben mehr als doppelt so viele Befehle,
Register und dann kommt auch noch ein umfangreiches Cache und Pileining
System dazu, dass es damals nicht gab.
Die 8086 bis 80386 Prozessoren (vielleicht sogar die 486er) war kaum
komplexer als AVR's. Sie hatten nur mehr Pins und breitere Register. Und
natürlich war der Befehlssatz besser, aber nicht komplizierter - eher
einfacher.
Schreiber schrieb:> Das verträgt sich nur begrenzt mit einem kleinen Smartphon und gibt> sicher keine brauchbare Akkulaufzeit.
Die von Intel für Smartphones und Tablets gebauten Atoms waren, als sie
neu waren, durchaus konkurrenzfähig. Weniger Cores, die aber schneller.
Das Strombudget wird sowieso weniger vom Chip vorgegeben, als von Gerät,
denn im Smartphone lässt sich nur begrenzt viel Wärme abgeben. Die
hauptsächlich von Asus angebotenen x86-Androids waren technisch durchaus
auf der Höhe.
Das Tempo der Entwicklung durch die Konkurrenz der diversen ARM Cores
ist aber schneller, als es Intel lieb war. Immerhin konstruiert nicht
nur ARM selbst Cores. Qualcomm, Apple und Samsung bauen auch welche,
teils komplett selbst, teils modifizierte.
Intel konservierte seine Atoms hingegen über mehrere Jahre ohne
wesentlich Änderungen, während ein ein Jahr alter ARM Core oft schon zum
alten Eisen zählt. Da man aber für einen Smartphone-SoC keine $500
verlangen kann, und der Markt eher zögerlich reagierte, war das kein
gutes Geschäft für Intel.
Zudem drückte Intel mit billig-SoCs für Blackboxes/Tablets den Markt von
vergleichsweise teuren Prozessoren für lowend-Notebooks. Bei jedem
Atom-Netbook an Stelle eines i3-Notebooks ging Intel Geld durch die
Lappen. Mein eeeBook hat solch einen Tablet-Atom drin, ist also
technisch gesehen ein Tablet mit Tastatur statt Touchscreen.
Diesen Markt voll zu bedienen hat Intel daher m.W. abgekündigt. Und
bedient Tablets künftig lieber mit eingedampften Notebook-Prozessoren,
statt dafür eine eigene Schiene zu fahren.
A. K. schrieb:> Die von Intel für Smartphones und Tablets gebauten Atoms waren, als sie> neu waren, durchaus konkurrenzfähig. Weniger Cores, die aber schneller.> Das Strombudget wird sowieso weniger vom Chip vorgegeben, als von Gerät,> denn im Smartphone lässt sich nur begrenzt viel Wärme abgeben. Die> hauptsächlich von Asus angebotenen x86-Androids waren technisch durchaus> auf der Höhe.
Alles richtig, nur:
Hier soll ein voll aufgeblasenes Windows nebst normalen Programmen auf
einem Smartphon genutzt werden.
Der Prozessor wird dabei lange auf hoher Auslastung laufen und
dementsprechend wird der Prozessor warm und der Akku leer.
Das kann man nicht mit dem Handy-Windows und kleinen Apps vergleichen.
A. K. schrieb:> Zudem drückte Intel mit billig-SoCs für Blackboxes/Tablets den Markt von> vergleichsweise teuren Prozessoren für lowend-Notebooks. Bei jedem> Atom-Netbook an Stelle eines i3-Notebooks ging Intel Geld durch die> Lappen.
Die Intel-Atom wurden ja nicht komplett abgekündigt, nur die
Handy&Tablet-Versionen davon. Alle anderen Versionen (auch die
Notebook-Versionen) sollen bleiben.
Zudem ist die Rechnung eine Milchmädchenrechnung. Wenn die ganz billigen
Intel-Atoms verschwinden, dann kann Intel entweder einen passenden
Nachfolger liefern oder AMD&VIA den Markt überlassen.
Schreiber schrieb:> Zudem ist die Rechnung eine Milchmädchenrechnung. Wenn die ganz billigen> Intel-Atoms verschwinden, dann kann Intel entweder einen passenden> Nachfolger liefern oder AMD&VIA den Markt überlassen.
Das Segment abseits der Performance ist irgendwie nicht so das Ding von
Intel. Da sind sie äusserst wankelmütig. Zum einen wollen sie unbedingt
mitspielen, weil sie ja so tolle Hechte sind, zum anderen sind die
Margen da aber klein und der Supportaufwand recht gross. Noch dazu wird
sowas nicht von den üblichen Verdächtigen (Asus, ...) verbaut, sondern
von aus Intel-Sicht niederen Wesen. Das geht dann so 1-2 Jahre gut, dann
wird das eingestampft (wenn die Mehrzahl der Kundendesigns mangels
Support untergegangen ist und keiner die Chips abnimmt) und 3-4 Jahre
später wirds wieder woanders probiert.
Wir sind da mal mit einem STB-Chip (CE42xx) etwas reingefallen. Tolles
Ding, preismässig OK, aber Support unter aller Kanone.
Schreiber schrieb:> Zudem ist die Rechnung eine Milchmädchenrechnung. Wenn die ganz billigen> Intel-Atoms verschwinden, dann kann Intel entweder einen passenden> Nachfolger liefern oder AMD&VIA den Markt überlassen.
Gibts von AMD Pläne für den 5W Markt? Darin Geld zu versenken lohnt sich
für Intel eigentlich erst, wenn man mit dem Geld die x86-Konkurrenz
gleich mit versenkt.
> Mit dem x86-64 kommt noch ein Dutzend weiterer Register hinzu.> Kommen bei dir 8 auf ein Dutzend? ;-)
Marketing funktioniert so: 4 von den 8 Registern kann man vorwärts und
rückwärts benutzen, daher ist es legitim, sie als 12 zu zählen. :-)
x86 schrieb:> Weiß das jemand, warum man x86 CPUs nur als große dicke Mikroprozessoren> kriegt, aber vom recht teuren Intel Edison mal abgesehen, nirgends als> SoC für wenig Geld für Mikrocontrolleraufgaben?
Wozu? Die Antwort ist doch ganz einfach:
unterschiedliche Aufgabenfelder --> unterschiedliche Hardware.
Mit den heutigen PC-CPU's hat man Rennpferde, die zwar soviel Leistung
in Wärme umsetzen, daß man sie kühlen muß, aber dafür hat man eben auch
Rechenleistung in Größenordnungen, wo Zeugs für Embedded noch lange
nicht in die Nähe kommt. Ist ja nicht nur die schiere Taktfrequenz, die
sich jenseits von 2 Gigahertz tummelt, es sind auch die gewaltigen
Datenbreiten auf den Bussen, die für Durchsatz sorgen, die
Gleitkommafähigkeiten in Hardware, die riesigen Caches. Der Preis:
tausend Pins oder mehr.
Wer sollte mit derartigen Boliden seine selbstgeätzte Leiterplatte
bevölkern? Niemand natürlich.
Und obsolete Vorgängertypen braucht auch niemend mehr. Außer für die
Vitrine. Ich hab z.B. noch nen 8086 im Keramikgehäuse mit vergoldeten
Pins irgendwo in der Schublade. Nett anzusehen.
Fragen dieser Art grenzen ans Grundsächliche:
Ganz allgemein gesehen ist es immer schlecht, wenn eine Szene zur
Monokultur zusammenschrumpft, wie wir das in den letzten Jahren mit dem
Siegeszug des Arm-Cortex gesehen haben. Natürlich ist es gut, einen
guten leistungsfähigen µC zu haben, jaja! Aber bei jeder Monokultur ist
der Dampf raus, sprich der Konkurrenzdruck. Ich meine nicht den zwischen
Firmen, sondern den technischen, also den, der die Innovation antreibt.
Da kommt dann ganz leicht Stagnation und Scheuklappe auf - insbesondere
Letzteres. Soll doch keiner sagen, daß das Aufbohren des Cortex-A auf x
Kerne oder 64 Bit eine echte Innovation sei, es ist nur das Auswalzen
des Teigklumpens bis an den Rand seines Backbleches. Nebenher gesagt,
gilt all dies auch für Programmiersprachen.
W.S.
Hurra schrieb:> 80386> Es ist nicht toll.
Gegenüber dieser verbastelten Akku-Maschine waren der 68k und seine
6833x Controller-Ableger eine wahre Wohltat.
A. K. schrieb:> Gibts von AMD Pläne für den 5W Markt? Darin Geld zu versenken lohnt sich> für Intel eigentlich erst, wenn man mit dem Geld die x86-Konkurrenz> gleich mit versenkt.
Wenn AMD mal sowas wie Entwicklungssupport leisten würde hätten sie da
auch ne Chance. Aber das was aktuell geboten wird ist absolute Armut.
Die kleinen 5W-APUs takten nicht genug runter und sind somit in summe
deutlich heißer wie ein Atom. Díe Performance ist abseits von Grafik
unterurchschnittlich.
x86 schrieb:> Nun, der Vorteil läge im Know How der Softwareentwickler.> Den x86 Befehlssatz kennt jeder, bei ARM wäre ich mir da nicht so> sicher.
Jeder? Naja, ich jedenfalls kenn' ihn nicht. Und will ihn auch gar nicht
kennen.
Meine ganz persönliche Ansicht: das Intel-Zeug war schon Mist, als es
erfunden wurde und hat über die Jahrzehnte nur immer weiteren Mist
angesammelt, um ja der heiligen Kuh der Kompatibilität nix anzutun.
Für die reichlich verkorkste Architektur, die im Wesentlichen aus dem
Ballast der Jahrzehnte besteht, gibt es keine Existenzgrundlage als die
Kompatibilität zu ihren Vorgängern und ihren Preis, der sich aus den
Stückzahlen ergibt.
Warum sollte man sich das antun, wenn man nicht muß?
Markus F. schrieb:> Meine ganz persönliche Ansicht: das Intel-Zeug war schon Mist, als es> erfunden wurde und hat über die Jahrzehnte nur immer weiteren Mist> angesammelt, um ja der heiligen Kuh der Kompatibilität nix anzutun.
Genau so ist es. Schreib mal einen Bootloader für ein x86 und dann für
ein ARM System. Beim x86 musst du zuerst 1-2x Modi wechseln, dann
irgendeinen foo machen, beim ARM geht es quasi direkt los.
Und optimieren kann man umso besser desto simpler die Architektur ist.
x86 ist zum Teil durchaus ein Mindfuck und wenn man sich anschaut, was
die Hersteller ala Intel/AMD hier treiben für Befehlsoptimierung in der
CPU/Compiler weil die Programmeirer zu unfähig sind, CPU Manuals zu
lesen (wobei man hier schlichtweg von der Vielfalt erschlagen wird) und
zu realisieren, dass sie aktuell nur einen von drei Addierern benutzen
bezweifel ich, dass zum einen umfängliche Kenntnisse über die
Architektur und schon zweimal nicht über den x86 Befehlssatz vorliegen.
Markus F. schrieb:> x86 schrieb:>> Nun, der Vorteil läge im Know How der Softwareentwickler.>> Den x86 Befehlssatz kennt jeder, bei ARM wäre ich mir da nicht so>> sicher.>> Jeder? Naja, ich jedenfalls kenn' ihn nicht. Und will ihn auch gar nicht> kennen.>> Meine ganz persönliche Ansicht: das Intel-Zeug war schon Mist, als es> erfunden wurde und hat über die Jahrzehnte nur immer weiteren Mist> angesammelt, um ja der heiligen Kuh der Kompatibilität nix anzutun.>> Für die reichlich verkorkste Architektur, die im Wesentlichen aus dem> Ballast der Jahrzehnte besteht, gibt es keine Existenzgrundlage als die> Kompatibilität zu ihren Vorgängern und ihren Preis, der sich aus den> Stückzahlen ergibt.>> Warum sollte man sich das antun, wenn man nicht muß?
Itanium!
Aber die Kunden wollten nicht.
Intel Fan schrieb:> Aber die Kunden wollten nicht.
Aus gutem Grund, und der war nicht technischer Natur. Itanium ist
garantiert von den Zehennägeln bis zu den Haarspitzen zupatentiert, wäre
also ein Monopol geblieben. Mit Monopolpreisen.
Intel ahnte die mangelnde Begeisterung wohl und wollte sie deshalb dazu
zwingen. Wer 64 Bits wollte oder benötigte, der sollte auf Itanium
wechseln müssen. Ein 64-Bit x86 war von Intel nicht geplant. Eine
Rechnung, die Intel ohne AMD gemacht hatte.
