Was macht eigentlich einen Atmel-Mikrocontroller aus? Also, ich denke, ein Hauptaspekt ist, dass diese besonders günstig sind - es gibt ja bereits welche für 0,50 Euro? Oder zumindest 2 Euro bis 6 Euro. Ein Atmel AVR Atmega 8 kostet ja, glaube ich 6 Euro. Das ist insofern interessant, weil ein Intel-Prozessor kostet gut und gerne Mal, selbst wenn er nicht der teuerste ist 150 Euro. Also ich habe mir ja ein Mainboard, mit RAM und Prozessor beim Arlt gekauft - sie hatten ein Angebot - einen Prozessor - Intel-Core-i3, 8 GByte DDR4-RAM, dazu ein ASUS-Mainboard, zum selber zusammenbauen für 249 Euro. Man kann sich ja auch ein Board mit eingebauten Prozessor kaufen - Intel Celeron - ist inzwischen auch 4-Kern-Prozessor. Aber das Board mit Prozessor kostet ca. 80 Euro. Ich meine der Prozessor ist Onboard - ich denke, der Preis der Prozessors, würde man ihn so nehmen, wären 50 Euro und das Board 30 Euro, oder das Board 25 Euro und der Prozessor 55 Euro, etwas derart. Aber natürlich ist ein Prozessor selbst für 50 Euro deutlich teurer als ein Prozessor für 6 Euro, oder 1 Euro. Was macht eigentlich den Atmel-Prozessor aus? Nun, ich denke, im Intel-Prozessor ist vieles verbaut, was im Atmel nicht zu haben ist. Das fängt nicht mit Mehrkernprozessoren an. Das ist wohl eher das Resultat, von dem allem. Wichtig bei Mikrontrollern dieser Art ist, dass sie 8 Bit breit sind. Intel war ja sehr lange 32 Bit breit. Am Ende wurde es 64 Bit breit. Ich meine 16 Bit, das war ja schon eine Revolution. Dazu natürlich Segment- und Offset-Register zu verwenden, so, dass 16 Bit erreicht werden, das ist natürlich eine Idee von Intel - die Intel speziell macht. Von daher genügt es auch nicht zu sagen, Mac verwendete lange 68000-Motorola-Prozessoren. Oder Commodore. Das seien auch Prozessoren. Und genauso gut, das stimmt so nicht. Alle guten Ideen stammen von Intel - ebenso mit der MMU beim 386er. Natürlich gibt es das Konzept der MMU schon lange - aber das sagen wir so zielstrebig und legere um zu setzen, diese Idee kommt von Intel - und deswegen ist der Intel-Prozessor der bessere und allen anderen haushoch überlegen. Natürlich hat da Intel viel weiteres herumgefuhrwerkt. Ich meine, die ganzen späteren Segment-Register mit der Einführung des Protected Modes, auf dem Intel 386, als 32 Bit richtig populär wurde, diese Dinge, stammen alle von Intel, die zu gegeben nicht mehr so einfach zu programmieren sind, wie die Segment und Offset Register in Real Mode - ebenso die Standards, nach denen, Page Tables und Page Directories benutzt werden - alle diese Ideen stammen von Intel. Was später geschah, erzeugte nicht mehr einen solch deutlichen Eindruck, wie es am Anfang war. Natürlich war es Intel, was schon früh SSE und MMX einführte. Blos: Was ab dem 64-Bit-Modus geschah, war sehr vielseitig. Aber bisher kam alles von Intel - und nur von Intel - und Intel hat es gut verkauft. Als der 64-Bit-Modus eingeführt wurde, entstanden verschiedenste Strategien. Doch schaut man sich das Produkt genau an, ich meine, schenkt man dem Vertrauen, was richtig ist, dann ist Intel trotzdem besser. Ich meine, zum Beispiel Intel kam früher mit den Mehrkernprozessoren, wieder ein Punkt, unschlagbar für Intel. Man muss andere Strategien von Prozessoren bedenken, wie das Pipelining - das ist wohl mit die wichtigste Strategie überhaupt, von einem Prozessor im Sinne von von-Neumann, zu einem solchen Stück, wie sie heute sind. Das Pipelining setzt eine gute Sprungvorraussage voraus. In diesem Falle sieht es schon wie ein großes Kunststück aus, was Intel mit dem Pipelining tat, wie viele Stufen hat das? 25 Stufen? Da ist natürlich Intel wieder derjenige, der den Takt vorgibt. Aber es gibt viele weitere Entwicklungen im Zuge des Mehrkernprozessors. Erstens Mal: Mehrkernprozessor, da ist Intel, derjenige, der zu fragen ist. Wenn es darum geht: Intel. Intel zeigt sich aber überhaupt immer gut aufgelegt. Es ist zum Beispiel normal, wenn man sich einen Prozessor kauft, dass man nicht einfach einen Prozessor kauft, sondern noch einen Lüfter dazu bekommt. Und man bekommt eine Intel-Wakü. Das heißt auch außerhalb von dem, was drin steckt, Intel ist bereit, seine Produkte jederzeit nach besten Wissen und Gewissen zu pflegen. Das ist glaube ich der Unterschied, zu allem andere: Sie haben ihre Produkte voll im Griff - sie lieben ihre Produkte. Und das ist der Unterschied: Sie machen es gerne. Was macht jetzt eigentlich einen Intel-Prozessor im Gegensatz zu einem Atmel, so besonders. Na ja, zunächst, ich denke Mal, der Befehlssatz - auch hier hat Intel einen Standard vorgegeben. Ich denke der Atmel-Befehlssatz könnte auch ein Standard sein - aber eben für kleinere Mikrocontroller. Bei solchen Prozessoren, wie die von Intel, ist es einfach Intel, der den Befehlssatz diktiert. Aber: Atmel hat einen Befehlssatz, der nicht bekannt ist und Intel einen, der sehr bekannt ist. Was allerdings einen "langsamen" Mikrocontroller ausmacht, ist nicht, dass nur der Takt langsamer ist. Ich meine bei Mikrocontrollern von Atmel, ist er max. 8 MHz groß. Er kann aber gut bei einem MHz oder weit darunter liegen. Um einen Prozessor besonders schnell zu machen, ist allerdings das Pipelining notwendig. Wenn man sich einen Maschinenbefehl wie ADD vorstellt, dann besteht er aus vielen Mikrobefehlen. Der erste ist zum Beispiel, man muss die Register füllen, dann müssen sie in der ALU addiert werden, dann müssen das Ergebnis in der Zielregister zurückgeschrieben werden. Das wären also schon drei Schritte, normalerweise gibt es aber 5, Minimum. Nur: Wir müssen auch auf den Arbeitsspeicher zu greifen, es sind also immer mehrere. Wenn wir jetzt einen normalen Befehl angucken, dann wird der Befehl ADD, zum Beispiel ausgeführt. Mikrooperation (1), Mikrooperation (2), ... werden ausgeführt, für einen Befehl. Es wäre lohnenswert darüber nach zu denken, wenn der einen Befehl ausgeführt wird, dann ist er inzwischen bei Mikroperation (5) sagen wir. Könnten dann nicht die vier vorherigen Befehle bereits mit den Mikrooperationen 1 bis 4 ausgeführt werden? Das ist Pipelining im eigentlichen Sinn. Es gibt ein Modell für Pipelining - DLX-Pipeling - das ist ein allgemeines Modell - man findet es im Kurs "Computersysteme II" der Fernuniversität in Hagen. Eine DLX-Pipeling ist ein graphisch gedachtes Modell, was die Stufen vorstellt. Man kann sich das Pipelining, nämlich als Schaltplan bzw. physische Struktur vorstellen. Während wir zunächst davon ausgehen, wir führen Mikrooperation 4 von dem nachfolgenden Befehl aus, während wir bei Mikrooperation 5 sind des ersten Befehls sind, denken wir an etwas, wie eine raffinierte zeitliche Schaltung - wenn wir an Pipelining denken. Das muss so aber nicht sein. Man kann ein graphisches Modell bilden, nachdem die Stufen alle einzeln zu Papier gebracht werden. Und quasi physisch von einer Stufe in die Nächste fließen. Was dabei wichtig ist: Das ist die Sprungvorhersage. Wir haben nämlich ein Problem: Wenn wir bei einem Befehl, wie JE, JNE, JB, JBE, ... also bedingten Sprüngen landen, dann muss an dieser Stelle eine Entscheidung getroffen werden, ob gesprungen werden soll oder nicht. Doch für die nachfolgenden Befehle steht noch nicht fest, ob gesprungen werden soll, oder nicht - weil es handelt sich um Pipelining - und der bedingte Sprungbefehl ist noch nicht ausgeführt. Wir müssen also eine Entscheidung treffen, wenn wir noch nicht wissen, ob wir springen oder nicht, weil wir je nach dem einen anderen Code ausführen - entweder den, wenn wir springen oder nicht springen - nun: Es gibt hier kein allgemein gültiges 100%es Konzept. Es kann immer sein, dass doch gesprungen wird, obwohl wir vorausgesagt haben, dass wir nicht springen und umgekehrt. In diesem Falle muss so oder so, der gesamte Code, der hätte eigentlich ausgeführt werden soll, neu geladen werden. Doch, dass kann den Prozessor verlangsamen. Wenn wir jedes Mal den Code neu laden müssen, nimmt das immens Zeit in Anspruch. Deswegen gibt es eine Sprungvorhersage. Auch diese macht irgendwann einen Fehler: Schauen wir uns eine Schleife an, die hundert mal ausgeführt wird, in C wäre das WHILE (i < 100) i++; Wir denken uns das Ganze entsprechend in Assembler. Eine gute Sprungvorhersage würde erkennen, dass die Schleife auf jeden Fall ganz oft durchlaufen wird. Aber keine Sprungvorhersage kann es erledigen, dass sie mit eindeutiger Sicherheit sagen könnte, wann die Schleife aufhört. Also irgendwann muss neu geladen werden. Eine gute Sprungvorhersage, kann mit komplizierten Situationen besser fertig werden, als eine schlechte. Es kommt auf die Strategie der Sprungvorhersage an. Und dieses Konzept der Sprungvorhersage ist beim Pipelining besonders wichtig - und da ist Intel einfach ein King, wenn es um Pipelines mit 25 Stufen geht. Sie sind durch die Stufen ein King, aber auch durch die Sprungvorhersage. Das ganze wird übrigens noch schlimmer, wenn wir zu Mehrkernprozessoren übergehen. Man muss sich Mehrkernprozessoren wie ein Netzwerk vorstellen - aber nicht wie irgendeines. Es gibt unterschiedlichste Netzwerktopologien, die nicht unbedingt etwas miteinander zu tun haben. Ein Mehrkernprozessor hat, was das betrifft, nichts mit TCP/IP gemein. Worauf es bei Mehrkernprozessoren ankommt: Wir können uns vorstellen: Wenn wir 4 Kerne haben und vier Zeitraubende Prozesse, dann könnte das Betriebssystem jeden der Prozesse auf Kern1, Kern2, Kern3, Kern4 verteilen. Das ist aber nicht das Ziel, beim Mehrkernprozessoren das Betriebssystem mit den Kernen zu belasten. Vielmehr sollte der Prozessor nach außen einfach ein normaler Prozesor sein und der Benutzer möchte diesen nutzen, als ob er es nicht wüsste, dass mehrere da sind. Die Aufgabe soll der Prozessor selber übernehmen. Er soll das so machen, als wäre es ein Prozessor. Dafür gibt es eigene Protokolle - findet man auch in Computersysteme II, der Fernuniversität in Hagen. Es wurde allerdings zu einem Problem: Nämlich als man das Pipelining mit Mehrkernprozessoren mischte, stand man vor einer neueren Herausforderung bei der Sprungvorhersage: Man erschuf den Tomasolu-Algorithmus und das Score-Boarding. Das Prolem ist, dass sich jetzt ein Bug auftat, den man erst später merkte, und unter dem leiden alle Prozessoren, dieser Art bis heute. Dieser Bug ist allerdings ein Problem, denn er stellt ein Sicherheitstechnisches Problem dar. Das heißt man kann einen Computer hacken auf Grund eines Bugs, der nicht in der Software besteht, sondern auf Grund der Hardware. Das ist aber kein Vergehen von Intel - in diesem Falle hat Intel das verwendet und umgesetzt, was Universitäten anpreisen und angepriesen haben - Tomasolu und Scoreboarding. Derartige Dinge sind natürlich alle auf einem Mikrcontroller mit 8 Bit und 1MHz nicht notwendig. Man braucht keine Score-Boarding, keinen Tomasolu-Algorithmus, man braucht keine Architektur, die mehrere Kerne unterstützt. Man braucht kein Pipelining. Man braucht keine Sprungvorhersage. Man braucht keine MMU. Und keine Segmentregister usw. Wobei man letzteres schon implementieren könnte. Würde man das aber tun, hätte man am Ende vielleicht sogar erneut ein Problem. Weil: Die 8-Bit-Mikrontroller sind als solche vorgesehen - und für die entsprechend großen bzw. kleinen Aufgaben vorgesehen. Zum Beispiel der Steuerung von Schrittmotoren oder ähnlichem. Würde man jetzt damit beginnen, eine MMU um zu setzen und Segmentregister, würde sich irgendwann die Frage stellen, warum eigetnlich keine Pipelining und eine Sprungvorhersage. Am Ende würde man sich mit Mehrkernprozessoren abgeben und man müsste Intel Konkurrenz machen. Man müsste auf dem Markt damit Fuß fassen, man hätte nichts gewonnen - weil man wollte kleine 8-Bit-Controller herstellen - und wer fragt: Man könnte es trotzdem versuchen. Gegenfragte: Wer bedient dann das Segment, was sich mit 8-Bit-Controllern befasst? Aber: Wenn ich mich für einen Controller entscheiden müsste, der kleine Aufgaben erledigt, und kein Multitasking-Betriebssystem braucht, dann würde ich mich für Atmel AVR entscheiden. Ganz einfach. Und deswegen würde ich die nicht verachten. Den Motorola 68000 würde ich zwar als solchen nicht verachten, weil ich anderes nie verachte, trotzdem wäre das nicht der Prozessor für den ich mich primär entscheiden würde. Für Atmel AVR Atmega8 schon. Und eben für Intel. Andere, für die würde ich mich wahrscheinlich weniger entscheiden. Also Atmel Intel Aber: Vielleicht letzter interessanter Gedanke zum Schluss. Wir sind es gewohnt, eine Maschine zu haben, die Maschinenbefehle ausführt, wie ADD, SUB, MUL, DIV. Gleichzeitig können wir jedes Scheme-Programm und jedes C-Programm, in ein Binärprogramm übersetzen, das aus Maschinenbefehlen besteht. Wäre es nicht möglich eine Scheme-Machine oder eine C-Machine zu entwickeln - ich würde davon abraten - aber theoretisch. Ich meine wir kennen es: Stackarchitekturen sind wirklich gebaut wurden. Da es aber zu jedem Scheme-Programm und zu jedem C-Programm, ein entsprechendes Binärprogramm gibt, wäre die Frage, ob man gleich eine C-Machine oder eine Scheme-Machine baut. Was auch noch interessant ist: Atmel ist in einer Hinsicht sehr sauber: Es hat 32 Register auf dem Atmel Atmega 8. Nämlich r0 bis r31. Besonders interessant ist, dass diese Teil des Arbeitsspeicher sind. Das ist ein Vorteil von Atmel, wo Atmel sehr sauber ist. Intel hat die typischen Register AX, BX, CX, DX, SP, BP, SI, DI und die Segmentregister CS, DS, SS, ES. Das ist auch gut so - also so war es auf dem 8086er. Es gibt inzwischen mehr. Aber: Es ist trotzdem gut. Natürlich ist ein Prozessor, der einfach 64 oder 128 gleichwertige Register anbietet, sicher interessant - aber bei Intel ist dieses Konzept eben da und es ist nicht schlecht.