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.
Wozu sollte das gut sein? Der einzige Grund für Intel wäre Windows, aber das ist für µC-Aufgaben ungeeignet.
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: > Die Compiler sind ebenfalls hochoptimiert. Du kannst davon ausgehen, daß das auf ARM-Compiler ebenso zutrifft.
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.
Von AMD gibts die Geode-Familie. Aber mit TQFP64 ist da auch nichts ;)
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
x86 schrieb: > Mit dem x86-64 kommt noch ein Dutzend weiterer Register hinzu. Kommen bei dir 8 auf ein Dutzend? ;-)
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.
:
Bearbeitet durch User
A. K. schrieb: > Gibts von AMD Pläne für den 5W Markt? Pläne für die Zukunft? Keine Ahnung. Was es aber schon jetzt gibt sind einige APUs (CPU mit eingebauter Grafikkarte) http://products.amd.com/en-us/search?k=LaptopProcessors#Default=%7B%22k%22%3A%22LaptopProcessors%22%2C%22r%22%3A%5B%7B%22n%22%3A%22PlatformOWSCHCM%22%2C%22t%22%3A%5B%22%5C%22%C7%82%C7%825461626c6574%5C%22%22%5D%2C%22o%22%3A%22OR%22%2C%22k%22%3Afalse%2C%22m%22%3A%7B%22%5C%22%C7%82%C7%825461626c6574%5C%22%22%3A%22Tablet%22%7D%7D%5D%7D
> 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.
> Aber bei jeder Monokultur ist > der Dampf raus, sprich der Konkurrenzdruck. Mehr als 300Mhz sind sowieso nicht machbar - sagte Intel einst.
Stimmt doch gar nicht: https://en.wikipedia.org/wiki/Intel_80386EX Schon etwas überaltet, aber immerhin. Wir hatten das Ding in Microcontrollertechnik. Es ist nicht toll.
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.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.