Hallo, mir geht es hier um konzeptionelle Dinge der zukünftigen Rechnerarchitektur und möchte durchaus auch sehr subjektive Meinungen von euch hören. Angenommen, man hätte eine Maschine, die ein oder mehrere Register besitzt. Unendlicher, linear addresierbarer Speicher ist vorgegeben. Es stehen zwei Maschinen zur verfügung: Die Erste kann ziemlich schnell den Speicher addressieren und aufrufen. Lade- und Schreiboperationen vom/zum Register sind sehr schnell. Auf das Register angewandte Operationen sind ebenfalls schnell. Die zweite hat eher einen gemächlichen Speicherzugriff, dafür aber 32 Register. Operationen auf die Register bzw. zwischen ihnen sind unendlich schnell, Speicherzugriffe sind dafür signifikant langsamer. Welche Maschine würdet ihr auswählen? Freue mich auf Meinungen, Iwan
Иван S. schrieb:
> Freue mich auch Meinungen,
Worüber denn? Ist 'ne typische Seminaraufgabe.
Als Universalmaschine die erste (Bauchgefühl). In der Signalverarbeitung, wenn ich weiß, dass ich einen 31-Tap-FIR-Filter implementieren muss: die zweite ;-)
@ Иван S. (ivan) >Angenommen, man hätte eine Maschine, die ein oder mehrere Register >besitzt. Unendlicher, linear addresierbarer Speicher ist vorgegeben. Sehr realistisch. So wie die Turingmaschine zur Lösung praktischer Rechenaufgaben ;-) >Die Erste kann ziemlich schnell den Speicher addressieren und aufrufen. >Lade- und Schreiboperationen vom/zum Register sind sehr schnell. Auf das >Register angewandte Operationen sind ebenfalls schnell. Was praktischerweise nur auf eher kleine und "langsame" Speicher zutrifft. >Die zweite hat eher einen gemächlichen Speicherzugriff, dafür aber 32 >Register. Operationen auf die Register bzw. zwischen ihnen sind >unendlich schnell, Speicherzugriffe sind dafür signifikant langsamer. Das gilt quasi für jeden PC, trotz DDR2 Speicher. Weshalb die Dinger Dutzende (Hunderte?) Register in der CPU haben, dazu zwei Stufen Cache mit mittlerweile Mbytes etc. >Freue mich auch Meinungen, Schön dass du dir dazu Gedanken machst. Aber du solltest dir vielleicht besser erstmal den Istzustand und ein paar Grundlagen erarbeiten. Sonst wird die Diskussion zwar lang und wild, aber wenig fundiert. (ein Schelm, wer böses denkt ;-) Und den Begriff unendlich solltest du schnell vergessen, der ist nämlich rein philosophischer Natur ;-) MfG Falk
Иван S. schrieb:
> Welche Maschine würdet ihr auswählen?
Da wir hier schon bei Unendlichkeiten sind: Eine unendlich schnelle
Null-Register-Turing-Maschine. Kann definitionsgemäss alles berechenbare
berechnen, ist dem Prinzip nach extrem einfach aufgebut und seit langem
bekannt.
Wenn dir Unendlichkeiten nur dort behagen, wo du sie selber postulierst,
dann bevorzuge ich bei Controllern Architekturen, die für die gestellte
Aufgabe schnell genug sind und mir wenig Architekturartefakte wie
Pointer-Attributierung für Adressräume in den Weg legen.
Und wenn wir über maximal erzielbare Performance einer Technologie
reden, statt über eine dem Problem angemessene Performance, dann ist der
Speicher beider Architekturen ungefähr gleich schnell und die
registerorientierte CPU letztlich schneller, benötigt aber mehr
Chipspace als eine Akkumulator-orientierte CPU. Was freilich bei genug
Zeug drumherum irgendwann nicht mehr ins Gewicht fällt. 1mm² mehr Platz
ist bei einem 5mm²-Chip relevant, 0.1mm² bei einem 20mm² Chip nicht.
Das Ziel akkumulator-orientierter CPUs ist die Minimierung des Aufwands,
nicht die Maximierung der Performance. Das ist so, seit es Computer
gibt. Viele Mainframes der 50er verwendeten Akkumulatoren (z.B. IBM 70x)
weil Register schweinemässig teuer waren. Ungefähr in den 60er-Jahren
wurde es mit vertretbarem Aufwand möglich, CPUs schneller Rechner mit
etlichen Registern zu versehen, und in dieser Dimension der Rechner sind
die Akku-Architekturen infolgedessen allmählich verschwunden.
Wegbestimmend waren hier CDC6600 und IBM360, Telefunken hoppelte mit der
TR440 und ihrem Akkumulator etwas hinterher.
Dass Mikroprozessoren ein Jahrzehnt darauf damit wieder mit Akkus
angefangen haben, lag daran, dass Single-Chip CPUs damals begrenzten
Platz zur Verfügung hatten und ein 6502 durch Minimierung der Register
billiger produziert werden konnte. Sobald genug Platz für Register drauf
war hat man die auch implementiert (8086, 68000). Gestorben waren die
8-Bitter deswegen nicht, aber sie migrierten in den Embedded-Bereich,
und dorthin wo die Kosten entscheidend waren (C16,C64).
Und dabei ist es bis heute geblieben. Andere Varianten hat es zwar noch
ab und zu gegeben, ob Stack-basierend (Burroughs, HP, x87) oder
ausschliesslich speicherbasierend (Intels 432-Desaster), aber das waren
stets Sackgassen. Die lebenslustigste Sackgasse davon war x87, wurde
aber mittlerweile durch SSE abgelöst.
A. K. schrieb: > Иван S. schrieb: > >> Welche Maschine würdet ihr auswählen? > > Da wir hier schon bei Unendlichkeiten sind: Eine unendlich schnelle > Null-Register-Turing-Maschine. Kann definitionsgemäss alles berechenbare > berechnen, ist dem Prinzip nach extrem einfach aufgebut und seit langem > bekannt. Klar wäre die die Schnellste. Nur unendlich schneller Speicher (bzw. ein unendlich schnelles Band) ist nicht in Sicht. > Wenn dir Unendlichkeiten nur dort behagen, wo du sie selber postulierst, > dann bevorzuge ich bei Controllern Architekturen, die für die gestellte > Aufgabe schnell genug sind und mir wenig Architekturartefakte wie > Pointer-Attributierung für Adressräume in den Weg legen. Das sehe ich ähnlich... > Und wenn wir über maximal erzielbare Performance einer Technologie > reden, statt über eine dem Problem angemessene Performance, dann ist der > Speicher beider Architekturen ungefähr gleich schnell und die > registerorientierte CPU letztlich schneller ...wohingegen ich dies konträr sehe. Irgendwie hab' ich im Bauch, daß die Einregistermaschine gewinnt. Kommt natürlich auf den Einsatzzweck an. Ausserdem bin ich nur Hauptschulabgänger, deshalb verstehe ich wohl auch nicht alle Zusammenhänge. > benötigt aber mehr Chipspace als eine Akkumulator-orientierte CPU. > Was freilich bei genug Zeug drumherum irgendwann nicht mehr ins Gewicht > fällt. Naja, mehr Chipspace bedeutet ja auch wiederum eine langsamere Taktung. > Das Ziel akkumulator-orientierte CPUs ist die Minimierung des Aufwands, > nicht die Maximierung der Performance. Das ist so, seit es Computer > gibt. Viele Mainframes der 50er verwendeten Akkumulatoren (z.B. IBM 70x) > weil Register schweinemässig teuer waren. Ungefähr in den 60er-Jahren > wurde es mit vertretbarem Aufwand möglich, CPUs schneller Rechner mit > etlichen Registern zu versehen, und in dieser Dimension der Rechner sind > die Akku-Architekturen infolgedessen allmählich verschwunden. > Wegbestimmend waren hier CDC6600 und IBM360, Telefunken hoppelte mit der > TR440 und ihrem Akkumulator etwas hinterher. Danke für den Exkurs. Gruß,Iwan
Falk Brunner schrieb: > Das gilt quasi für jeden PC, trotz DDR2 Speicher. Weshalb die Dinger > Dutzende (Hunderte?) Register in der CPU haben, Der Intel Pentium 4 hatte bereits über hundert. Intels IA64 (Itanium) hat nicht nich so versteckt wie x86, sondern 2x 128 Register sichtbar. > dazu zwei Stufen Cache mit mittlerweile Mbytes etc. Mittlerweile nicht selten 3 Stufen.
Ich würde sagen, vom heutigen Zeitpunkt an gewinnt die erste Maschine. Die reine Performance der heutigen Prozessoren reicht für fast alle interaktiven Anwendungen. Worauf man noch warten muss sind die großen Jobs, wie z.B. Videos transkodieren, Datenbankabfragen, Rendering, allgemein Prozesse, die viele Daten benötigen. Ein wirklicher Performancesprung ist aus heutiger Sicht also am ehesten mit schnellerem Speicherzugriff zu schaffen.
Иван S. schrieb: > ...wohingegen ich dies konträr sehe. Irgendwie hab' ich im Bauch, daß > die Einregistermaschine gewinnt. Wenn du mal davon ausgehen willst, dass bei den Herstellern nicht nur Dummköpfe sitzen, dann darfst du auch davon ausgehen, dass dies nicht zutrifft. Spätestens wenn wir zum PIC32 mit seinem MIPS-Core bewegen (Cortex-M3-Konkurrent), dann wird auch klar warum: Aufeinanderfolgende Operationen auf einen Akkumulator sind sehr oft voneinander abhängig. Folgebefehle müssen warten. Aufeinanderfolgende Operationen auf einen leidlich grossen Registersatz sind weit weniger oft abhängig. Das Pipelining, das man bei einem STM8 vergleichbarer Taktrate für 1-Takt Load-Execute Befehle benötigt, steht beim MIPS-Core dem Programmierer offen. Was bedeutet, dass man beim klassischen MIPS-Core direkt auf einen Load-Befehl jeden Befehl verwenden darf, der das geladene Register nicht verwendet. Bei gepipelinetem Load-Execute auf einen Akku geht dies jedoch nicht, da der zweite Befehl recht oft auf das Ergebnis des ersten warten muss. Nennt sich Pipeline-Interlock. Um eine Akku-Architektur davon zu befreien muss man die Out-Of-Order und Register-Renaming Methoden heutiger PC-Prozessoren verwenden (seit AMD K5, Intel PentriumPro üblich). Das könnte man zwar tun, aber der Platzvorteil wäre nicht spürbar, da beim dafür nötigen Aufwand die Anzahl der für den Programmierer sichtbaren Register keine praktische Rolle mehr spielt (z.B. wenn 1 vs 32). > Naja, mehr Chipspace bedeutet ja auch wiederum eine langsamere Taktung. Diese Annahme ist falsch.
Ich meine, daß solche Interna heutzutage von untergeordneter Bedeutung sind - der Compiler richtets. Der muß entsprechend gut sein. Welche von beiden schneller ist, kann man so nicht entscheiden. Dazu muß man Soft- und Hardware zusammen messen. Welche Maschine ich wählen würde, hängt zu einen vom Verwendungszweck, zum anderen vom Preis ab. Alles andere hat weder Hand noch Fuß.
Man könnte ganz dreist argumentieren: Ich wähle die Architektur, für die 'bessere' Unterstützung gegeben ist (Compiler, andere weiche Kriterien, etwa Support, Dokumentation etc.).
A. K. schrieb: > Aufeinanderfolgende Operationen auf einen Akkumulator sind sehr oft > voneinander abhängig. Folgebefehle müssen warten. Das müssten auch Folgebefehle auf Registermaschinen. > Aufeinanderfolgende Operationen auf einen leidlich grossen Registersatz > sind weit weniger oft abhängig. Eben jenes bezweifle ich. > [Pipeline-Interlock] Nicht relevant, da ebenso bei Registermaschinen vorhanden. > da beim dafür nötigen Aufwand die Anzahl der für den Programmierer > sichtbaren Register keine praktische Rolle mehr spielt (z.B. wenn 1 vs > 32). Was eben nicht heißen muss, daß ein Mehrregisterrechner schneller ist. >> Naja, mehr Chipspace bedeutet ja auch wiederum eine langsamere Taktung. > > Diese Annahme ist falsch. Danke für die Aufklärung. Uhu Uhuhu schrieb: > Ich meine, daß solche Interna heutzutage von untergeordneter Bedeutung > sind - der Compiler richtets. Der muß entsprechend gut sein. Der Compiler kann auch nicht zaubern. > Welche von beiden schneller ist, kann man so nicht entscheiden. Dazu muß > man Soft- und Hardware zusammen messen. Gefragt war (wenn auch implizit) welche Software schneller ist. > Welche Maschine ich wählen würde, hängt zu einen vom Verwendungszweck, > zum anderen vom Preis ab. Alles andere hat weder Hand noch Fuß. Beide stehen im Labor, sind also gleich teuer. Auch die Rechnezeit sei als gleich teuer angenommen. Den Verwendunszweck musz man sich selbst ausdenken!
Ich bin für ein Verschieben des Threads in de.alt.verhaltenspsychiologie . . .
Иван S. schrieb: > Beide stehen im Labor, sind also gleich teuer. Auch die Rechnezeit sei > als gleich teuer angenommen. Den Verwendunszweck musz man sich selbst > ausdenken! Unrealistisch.
Иван S. schrieb: > Das müssten auch Folgebefehle auf Registermaschinen. Nein. Beim Intel 486 fand die Adressrechnung einen Takt vor der Load/Execute-Stage statt (simplifiziert: decode-address-load/excute). Die Folge war, dass ein Folgebefehl, der in der Adressierung ein Register verwendete, das vom Vorgängerbefehl modifiziert wurde, einen Takt Pause einlegte musste. Beim Cyrix M1sc mit verlängerter Pipeline (simplifiziert: decode-address-load-execute) konnten es deshalb 2 Straftakte werden. Wenn ein solches Interlock beim STM8 nicht auftreten sollte (eine Pipeline-Dastellung davon habe ich nicht parat), dann bedeutet dies, dass alle Stufen von Adressrechnung, Load und Execute im gleichen Takt stattfinden müssen. Eine solche Implementierung begrenzt die Taktfrequenz auf viel geringere Werte als eine gepipelinte Implementierung. Wenn man andererseits eine Akku-Architektur für höhere Taktfrequenz mit der skizzierten Cyrix-Pipeline [decode - address calculation - operand-load - execute] versieht, dann treten zwischen einer Operation auf ein Indexregister und einer darauf folgenden Operation unter Verwendung dieses Indexregisters für die Adressierung des Operanden 2 Wartetakte auf. > Eben jenes bezweifle ich. Es bleibt dir unbenommen, eine (oder gleich alle) der Grundlagen der Entwicklung schneller Rechnerarchitekturen seit den 60er Jahren in Frage zu stellen. Als Laie mag man manchmal Dinge erkennen, für die ein Experte betriebsblind wird. Aber das heisst nicht, dass man als Laie automatisch besser ist als der Experte (ausser vielleicht bei Pferdewetten oder so). > Nicht relevant, da ebenso bei Registermaschinen vorhanden. Doch relevant, da bei Registern nicht selten vermeidbar. > Was eben nicht heißen muss, daß ein Mehrregisterrechner schneller ist. Natürlich muss es das nicht heissen. Eine alte registerorientierte Maschine kann langsamer sein als eine wesentlich neuere Akku-orientierte. Wenn die Registermaschine und die Akkumaschine aber die gleiche technologische Grundlage haben, dann ist die Akkumaschine nicht signifikant schneller als ein sinnvoll konstruierte Registermaschine. Eher langsamer, aber das hängt dann von den Details und dem Programm ab.
A. K. schrieb: > Иван S. schrieb: >> Das müssten auch Folgebefehle auf Registermaschinen. > > Nein. Beim Intel 486 [...] A. K., du verblüffst mich immer wieder mit Deinem Wissen. >> Eben jenes bezweifle ich. > > Es bleibt dir unbenommen, eine (oder gleich alle) der Grundlagen der > Entwicklung schneller Rechnerarchitekturen seit den 60er Jahren in Frage > zu stellen. Danke. > Als Laie mag man manchmal Dinge erkennen, für die ein Experte > betriebsblind wird. Aber das heisst nicht, dass man als Laie > automatisch besser ist als der Experte... Habe ich auch nie behauptet und steht mir zudem gar nicht zu. >> Was eben nicht heißen muss, daß ein Mehrregisterrechner schneller ist. > > Natürlich muss es das nicht heissen. [...] > Wenn die Registermaschine und die Akkumaschine aber die gleiche > technologische Grundlage haben, dann ist die Akkumaschine nicht > schneller als die Registermaschine. Meiner Meinung nach könnte sie schneller sein. > Ob sie langsamer ist hängt dann von Details und dem Programm ab. Also ist sie schon einmal nicht zwangsläufig langsamer. Genau das behaupte ich. Ausserdem behaupte ich, daß von Fall zu Fall die Akkumulatormaschine sogar schneller sein kann. Immer wieder schön mit Dir zu plaudern, Gruß, Iwan
Was bisher noch nicht angeschnitten wurde: Um auf Akkumaschinen eine gleichzeitige Ausführung unabhängiger Befehle zu ermöglichen, wie es bei PC-Prozessoren seit dem Pentium üblich ist, muss man einen weitaus höheren Aufwand treiben, als bei Registermaschinen (memory renaming statt register renaming, multiported cache statt multiported register file).
A. K. schrieb: > PS: Was bisher noch nicht angeschnitten wurde: Um auf Akkumaschinen eine > gleichzeitige Ausführung unabhängiger Befehle zu ermöglichen muss man > einen weitaus höheren Aufwand treiben, als bei Registermaschinen (memory > renaming statt register renaming, multiported cache statt multiported > register file). Du wirst albern! Allein schon wegen "gleichzeitige Ausführung unabhängiger Befehle". Iwan
Иван S. schrieb: > A. K., du verblüffst mich immer wieder mit Deinem Wissen. Wenn du dich mit jemandem "anlegst", der sich seit Jahrzehnten mit Rechnerarchitekturen befasst und der sich beispielsweise mal die Mühe gemacht hat, die Internas der Implementierung des AMD K7 jenseits der hierbei sehr spärlichen Dokumentation rauszukriegen... (so arg viele Spinner dieser Art gibt's ausserhalb der entsprechenden Hersteller nicht - und mit der Zeit kennt man sich, ein anderer wäre beispielsweise Agner Fog, http://www.agner.org/optimize, und zu deiner Beruhigung: Agner ist m.W. kein Informatiker).
Иван S. schrieb: > Du wirst albern! Allein schon wegen "gleichzeitige Ausführung > unabhängiger Befehle". Was bitteschön ist daran albern? Das ist Stand der PC-Technik seit Intels Pentium. Und weil der nun schon ein Weilchen her ist findet sich das mittlerweile beispielsweise auch im Cortex A8.
Иван S. schrieb: > Allein schon wegen "gleichzeitige Ausführung > unabhängiger Befehle". http://de.wikipedia.org/wiki/Superskalar
A. K. schrieb: > Иван S. schrieb: > >> Du wirst albern! Allein schon wegen "gleichzeitige Ausführung >> unabhängiger Befehle". > > Was bitteschön ist daran albern? Das ist Stand der PC-Technik seit > Intels Pentium. "gleichzeitige Ausführung unabhängiger Befehle": Bist Du Dir da sicher? Wir reden doch von einem Kern, oder? Oder meinnst du SIMD? Das hätte nichts mit "unabhängigen Befehlen" zu tun. Und wenn schon, brächte es doch keinen Vorteil. Iwan
Иван S. schrieb: > "gleichzeitige Ausführung unabhängiger Befehle": Bist Du Dir da sicher? Bombensicher. Der AMD K5 führt nachweislich folgende Schleife in einem einzigen Takt pro Interation aus, also 3 Befehle pro Takt, dauerhaft: mov eax, #0 l1: mov al, [esi,eax] mov ah, #0 loop l1 Diese Beispiel gewinnt noch, wenn man sich die Details zu den beteiligten Bussen und zum Renaming anschaut und es erklärt, warum der beim Takt nicht in die Pötte kam ;-). Man könnte übrigens auch noch einen 4. Befehl in der Schleife unterbringen. Das war das Limit. Erst Intels Core2 war wieder soweit, aber garantiert nicht bei dieser Schleife, das wird (in Takten) nie wieder geschlagen werden, da bin ich sicher. > Wir reden doch von einem Kern, oder? Ja. Keine Mehrfachcores, kein Hyperthreading. > Oder meinnst du SIMD? Nein.
Иван S. schrieb:
> Wir reden doch von einem Kern
Ja, ein Kern. Der hat aber mehrere Execution Units. Beim Athlon
von AMD sind es AFAIK sechs. Nicht alle Befehle lassen sich
parallel ausführen. Das hängt neben dem jeweiligen Befehl auch
vom aktuellen Zustand der Pipeline ab.
Es ist eine Weile her als ich mich damit befasst habe (Studium,
fast zehn Jahre her) aber ich meine der Athlon konnte damit im Schnitt
mehr als drei Befehle pro Takt abarbeiten.
Michael G. schrieb: > Es ist eine Weile her als ich mich damit befasst habe (Studium, > fast zehn Jahre her) aber ich meine der Athlon konnte damit im Schnitt > mehr als drei Befehle pro Takt abarbeiten. Dauerhaft sind es maximal 3, wobei kurzzeitig auch mal 8 oder so gleichzeitig in einem Takt in Arbeit sein können.
A. K. schrieb:
> Dauerhaft sind es maximal 3
Habe ich im Eiweißspeicher korrigiert.
Nochmal zum K5/K6: AMD hat doch von irgendeiner Firma die CPU
lizensiert und ihr praktisch nur den x86 Befehlssatz beigebracht.
Welche Firma war das und wurde das bereits der K5?
Später kam noch eine Busarchitektur vom Alpha dazu. Der K6?
Michael G. schrieb: > Nochmal zum K5/K6: AMD hat doch von irgendeiner Firma die CPU > lizensiert und ihr praktisch nur den x86 Befehlssatz beigebracht. Aus dem Bauch heraus: VIA, Cyrix oder IDT. > Später kam noch eine Busarchitektur vom Alpha dazu. Der K6? Kann man sehen wie man will. Iwan
Michael G. schrieb: > Nochmal zum K5/K6: AMD hat doch von irgendeiner Firma die CPU > lizensiert und ihr praktisch nur den x86 Befehlssatz beigebracht. Der K5 entstand ursprünglich im Rahmen von AMDs eigener 29000 RISC-Prozessorfamilie und wurde um ein x86-Frontend bereichert (und dem oben verwendeten irren 3fach-Renaming der Registerteile). Nur kam der bei der Taktfrequenz nicht in die Pötte, AMD hatte zuviel in einen Takt gequetscht, 117 echte Mega-Hz, verkauft als 166 Marketing-Hz, als Intel schon 200 brachte. Folglich hat AMD die unabhängige aber etwas klamme x86-Schmiede Nexgen aufgekauft, deren praktisch fertigen Nx686 vom vorgesehenen Spezialsockel mit Backside-L2-Cache in einen marktverträglicheren Sockel 7 gepresst und als AMD K6 verkauft. > Später kam noch eine Busarchitektur vom Alpha dazu. Der K6? Die fand man im K7/Athlon wieder, wurde später im K8 aber wieder fallen gelassen. Der Floating-Point-Unit von AMD ab K7 sieht man die Einflüsse des massgeblichen Alpha-Designers aber bis heute an. Der Einfluss der Nexgen-Designer auf den K7 ist jedoch als gering anzusehen.
Aha, Nexgen. Der Name wollte mir nicht einfallen. Das der Alpha-Bus nicht mehr genutzt wird wußte ich nicht. Nicht mehr viel übrig vom Alpha, was? Hat schon was Tragisches. Danke für die Info!
Michael G. schrieb: > Das der Alpha-Bus nicht mehr genutzt wird wußte ich nicht. Mit dem K8 kam ja das integrierte Speicherinterface und der mehrfache Hypertransport-Bus zur direkten Sockelkopplung. Intel hat erst unlängst diese beiden genialen Schachzüge nachvollzogen (die Kopplung mit QPI). > Nicht mehr viel übrig vom Alpha, was? Hat schon was Tragisches. Yep.
Je langsamer der Zugriff auf den Speicher ist, desto mehr Reg sind sinnvoll. (war auch der urspr. Grund, weshalb Computer mit Reg gebaut wurden) bereits 1969 hat DEC in einer Studie rausgefunden, dass 8...16 Reg das Optimum seien. Heute hören wir das von dem RX auch nochmal. (aber PDP8 hatte auch nur einen Akku, spätere hatten auch mehrere Reg)
MCUA schrieb: > Je langsamer der Zugriff auf den Speicher ist, desto mehr Reg sind > sinnvoll. (war auch der urspr. Grund, weshalb Computer mit Reg gebaut > wurden) Wobei man freilich dran denken sollte, dass eine Maschine wie die CDC6600 ohne Registersatz damals nicht möglich gewesen wäre. Auch mit doppelt so schnellem Speicher nicht.
>Ich meine, daß solche Interna heutzutage von untergeordneter Bedeutung >sind - der Compiler richtets. Der muß entsprechend gut sein. Ein Compiler richtet gar nichts. Der ist genauso "blöd" wie die CPU, da er diese nur benutzen kann.
Hallo, eigentlich ist die Frage historisch beabtwortet: Register machen Sinn, wenn der Zugriff deutlich schneller ist als der direkte Speicherzugriff, sonst könnte man ja mit dem Speicher direkt arbeiten. So schnellen Speicher gibt es aber nicht und wird es nicht geben, da ist die Endlichkeit der Lichtgeschwindigkeit vor: schon wegen der Signallaufzeiten kann ein GB grosser Speicher nicht annähernd so schnell sein wie Onchip-Register. Um diese "Zugriffslücke" (zwischen Register und Speicher) zu füllen, gibt es Register und die verschiedenen Caches. Daher sind Einregistermaschinen reine Theorie. Gruss Reinhard
> Daher sind Einregistermaschinen reine Theorie.
Hatte nicht der TMS99xx im TI99/4A nur ein Register auf seine
Register im Ram?
Es ist dann keineswegs Theorie. Die Sache ist ausgestorben weil
die Praxis bewiesen hat das es nichts bringt. :-)
Olaf
> Die Erste kann ziemlich schnell den Speicher addressieren und aufrufen. > Lade- und Schreiboperationen vom/zum Register sind sehr schnell. Auf das > Register angewandte Operationen sind ebenfalls schnell. > Die zweite hat eher einen gemächlichen Speicherzugriff, dafür aber 32 > Register. Operationen auf die Register bzw. zwischen ihnen sind > unendlich schnell, Speicherzugriffe sind dafür signifikant langsamer. Ein Register ? Kein Register (doch, den Stackpointer). Die reine Stackmaschine (Forth-Engine) gewinnt, wenn man davon ausgehen kann, daß Speicher auf den zuletzt zugegriffen wurde schneller verfügbar ist als Speicher auf den schon länger nicht mehr zugegriffen wurde, und wenn man postulieren kann, daß der Transfer von x nebeneinanderliegenden Speicherzellen (vom RAM ins Cache, vom 2nd level cache in die CPU) nicht so lange dauert wie x random vertreute Speicherzellen. Da eine Stackmaschine (bei unendlichem Speicher) keine Adressierungsgrenzen hat, aber statistisch häufiger auf nahe an TOS liegenden Werten operiert, müssten die Instruktionen (und deren adress fields bzw. datentypen specifier) nach statistischem Aufkommen codiert werden (häufigeres also kürzer, nach Huffmann oder so). Es gab solche Versuche (z.B. Transputer), aber durchgesetzt haben sich die schwieriger zu programmierenden (zumindest von einem Compiler aus) RISC-Maschinen (deren Befehlssätze heute alles andere als reduced sind). Man kann jetzt überlegen, warum das so war. Ich weiß, das manche (nicht real existierenden, virtuellen) Architekturen nach ihrem Aufwand durchgerechnet wurden um ihre maximal mögliche Performance zu bestimmen, kenne aber die Ergebnisse nicht, für deren Erreichen ja immer bestimmte Annahmen getroffen wurden.
Der TMS99xx hatte tatsächlich seine Register im Hauptspeicher. Ein CPU-internes Register zeigte auf diesen externen Registersatz. Ein derartiges Konzept (möglichst alle Register incl. Instruction Pointer / Status-Register ... ) im Hauptspeicher ermöglicht z.B. einen sehr schnellen Taskwechsel bei Interrupts. Das Konzept "mehrere einfach umschaltbare Registerbänke im Hauptspeicher" wurde damals ebenfalls in anderen Processoren (z.B. einigen Embedded Processoren in IBM-Maschinen) benutzt. Bernhard
Reinhard Kern schrieb: > eigentlich ist die Frage historisch beabtwortet: Register machen Sinn, > wenn der Zugriff deutlich schneller ist als der direkte Speicherzugriff, > sonst könnte man ja mit dem Speicher direkt arbeiten. Bei spekulativer Ausführung von Befehlen in Out-of-Order Prozessoren mit Renaming sowie bei superskalaren Prozessoren kommt etwas mehr hinzu. Sowas geht mit Registern weitaus einfacher als mit Speicher und diese Techniken werden durch extrem schnellen Speicher nicht überflüssig, da sie in Zusammenhang mit den heute üblichen tiefen Pipelines stehen. Zur Illustration: Auf das Integer-Registerfile eines AMD K7 können gleichzeitig 9 Lese- und 8 Schreibzugriffe stattfinden. Auf den D-Cache jedoch nur entweder 2 Lese- oder 1 Schreibzugriff, und das auch nur wenn kein Bankkonflikt auftritt.
Bernhard R. schrieb: > Der TMS99xx hatte tatsächlich seine Register im Hauptspeicher. Ein > CPU-internes Register zeigte auf diesen externen Registersatz. Yep. Wobei eine 6502 in gewisser Hinsicht 256 Register zweiter Klasse hatte. Hintergrund ist in beiden Fällen, dass damals der Prozessor kaum schneller war als der Speicher und ein externer Speicherzugriff folglich nicht annähernd so drastisch abbremste wie das heute der Fall ist.
MaWin schrieb: > Es gab solche Versuche (z.B. Transputer), aber durchgesetzt haben sich > die schwieriger zu programmierenden (zumindest von einem Compiler aus) Im Gegenteil. Nichts ist einfacher als ein Codegenerator für eine klassische Stackmaschine (*). Ein bischen komplizierter war es für mich beim Transputer, weil dessen Stack mit nur 3 Levels extrem limitiert war, aber auch das ist kein grosses Problem. Hässlich war eher, dass dem Transputer ein paar Befehle fehlten, die für die INMOSsche Zielsprache Occam nicht benötigt wurden, wohl aber für C (z.B. Verdopplung vom TOS). Der Transputer (und andere Stack-Maschinen) starb, weil dieses Prinzip sich höllisch schlecht beschleunigen lässt. Aufeinanderfolgende Befehle sind bei Stackmaschinen meistens voneinander abhängig, so dass eine einfache superskalare Ausführung mit Optimierung der Befehlsanordnung durch den Compiler, wie in den ersten entsprechenden Generationen von RISC-Maschinen und PC-Prozessoren (P5x), nicht in Frage kommt. Man muss also gleich zu einer sehr tief parallelisierenden Mikroarchitektur übergehen, um mehrere Sequenzen von Befehlen zu puffern und zu parallelisieren. Mit diesem Riesenschritt war eine kleine Schmiede wie INMOS (bzw. später Thompson) überfordert (Der Versuch einer Optimierung der Verbindungskanäle hin zu komplexen Netzwerken mit Hardware-Routing tat ein Übriges). *: Es sei denn du musst dies einem bestehenden Codegenerator beibringen, der für registerorientierte Maschinen konzipiert ist. Damit müssen beispielsweise Leute kämpfen, die GCC (oder PCC) x87-Code beibringen wollen. Ich zog es vor, den Codegenerator komplett wegzuwerfen und neu zu schreiben.
> Im Gegenteil. Nichts ist einfacher als ein Codegenerator für eine > klassische Stackmaschine (*). Sag ich doch. Nicht im Gegenteil. Ich sagte, man hat sich für die schwierigere entschieden, für die Registermaschine statt der Stackmaschine. > Der Transputer (und andere Stack-Maschinen) starb, weil dieses Prinzip > sich höllisch schlecht beschleunigen lässt Das halte ich nicht für die Ursache. Es lässt sich gut cachen, es lässt sich gut im voraus decodieren, es lassen sich gut Instruktionen wegoptimieren (eben alle die nur mit Datentransfer zu tun haben, die nur das machen, was Register-Renaming bei Registermaschinen wäre). > Hässlich war eher, dass dem Transputer ein paar Befehle fehlten Z.B. füllen eines Speicherbereichs zum Blitten. http://en.wikipedia.org/wiki/Transputer
MaWin schrieb: > Sag ich doch. Nicht im Gegenteil. Ich sagte, man hat sich für die > schwierigere entschieden, für die Registermaschine statt der > Stackmaschine. Yep, das hatte ich missverstanden. Allerdings war genau dies die Absicht, damals. Den Aufwand für Laufzeitoptimierung von der Hardware in den Compiler zu verlagern, indem man versucht, Folgebefehle voneinander unabhängig zu machen. Und so auch schon einfache Hardware mit geringer Puffertiefe schon superskalar werden konnte. Bei dem Aufwand, den man heute treibt, ist dieser Aspekt nicht mehr so entscheidend. Da liesse sich das wieder realisieren. Aber der Versuch, einen evolutionären Schritt zu überspringen, gibt meistens eine Bruchlandung. Manchmal technisch, oft kommerziell. Aus dem Wiki-Artikel zum Transputer: "The production delays gave rise to the quip that the best host architecture for a T9000 was an overhead projector.". Wobei auch heute dieser Aufwand etwas ist, dass eine kleine Schmiede besser vermeiden sollte. Sind ziemlich viele Teufelchen im Detail. XMOS hat gut daran getan, ein zweites solches Experiment zu vermeiden. Mit einer Parallelisierung in Form von ganz offiziell unabhängigen Threads wie bei den XMOS-Prozessoren tut man sich leichter.
PS: Der letzte Satz sollte besser heissen: Mit einer Beschleunigung in Form von ganz offiziell unabhängigen Threads wie bei den XMOS-Prozessoren tut man sich leichter (das erinnert mich übrigens an den I/O-Prozessor der CDC6600).
>Hintergrund ist in beiden Fällen, dass damals der Prozessor kaum >schneller war als der Speicher und ein externer Speicherzugriff folglich >nicht annähernd so drastisch abbremste wie das heute der Fall ist. Aber das ist ja heute (bei den meisten Controlern) genau so ! Die meisten Controler laufen bis ca 16..ca50 MHz, bei CPU <und> Speicher. Und somit sind diesen Controllern etliche Klimmzüge (wie bsp bei X86) total unnötig.
MCUA schrieb: > Und somit sind diesen Controllern etliche Klimmzüge (wie bsp bei X86) > total unnötig. In meinen Augen sind Register keine grässlichen Klimmzüge. Im Gegenteil, ich fand dem Umstieg von 6502 auf 68000 sehr angenehm. Wie schon jemand anders berichtete: In Assembler mag ich den Schritt zurück nicht mehr gehen und in C schon der Verfügbarkeit guter Compiler für registerorientierte Maschinen wegen auch nicht.
>> Und somit sind diesen Controllern etliche Klimmzüge (wie bsp bei X86) >> total unnötig. >In meinen Augen sind Register keine grässlichen Klimmzüge..... Nein, Register sind keine Klimmzüge, aber viele andere Ausführungs- und Steuer-einheuten -bsp Cacheverwaltung, mehrere ALUs, Registerrenaming, Sprungvorhersage- bei Prozessoren >= 200 MHz oder mehr, sind Klimmzüge (die auch viel Geld kosten), die man bei einem 50MHz-Prozessor heute nicht mehr braucht, weil der Speicher da genau so schnell ist wie Register, und die Rechenleistung auch so schlichtweg ausreicht. Und eine X86-CPU interessiert in der EmbeddedWelt so gut wie keinen.
MCUA schrieb: > Aber das ist ja heute (bei den meisten Controlern) genau so ! > Die meisten Controler laufen bis ca 16..ca50 MHz, bei CPU <und> > Speicher. Und trotzdem sind Register meist immer noch wesentlich schneller. In der Regel kann beim RAM (bzw. Cache) nur maximal ein Load oder Store pro Takt ausgeführt werden, während bei Registern zwei Loads und ein Store (typische Rechenoperation mit zwei Operanden- und einem Zielregister) innerhalb eines Zyklus durchgeführt werden können. Selbst bei im Vergleich zu Mikrocontrollern sehr aufwendigen CPUs wie dem AMD K10 hat der L1-Cache gerade mal zwei Ports (dass hier dann der Cache auch schon wieder ganze 3 Takte Latenz hat steht noch auf einem anderen Blatt). Die Register können dagegen sogar mehrere ALUs gleichzeitig mit Operanden versorgen und auch noch die Ergebnisse speichern. > Und somit sind diesen Controllern etliche Klimmzüge (wie bsp bei X86) > total unnötig. Das Einsparen von 2/3 der Takte (wenn alle Operanden in Registern liegen) würde ich nicht als "total unnötig" bezeichnen. Und viele "Klimmzüge" konkret beim X86 (ohne 64bit-Erweiterung) sind gerade dem Umstand geschuldet, dass X86 im Vergleich zu modernen Architekturen nur sehr wenige Register besitzt, die dazu auch noch grösstenteils jeweils mit unterschiedlichen Spezialfunktionen belegt sind. Andreas
Versuche, ohne lange Pipelines, komplexe Sprungvorhersage und out-of-order execution auszukommen, sind auch noch nicht so lange tot. IBMs nach wie vor verkaufter 4,xGHz Power6 Prozessor hat eine in-order Mikroarchitektur. Und IBMs erst vor einigen Jahren beerdigte in-order RS64-Schiene für den Sektor kommerzieller DV (iSeries, AIX) hatte es trotz sehr kurzer Pipeline immerhin bis 750MHz geschafft. Die beim vorgesehenen Einsatzgebiet mit weit höhere getakteten Prozessoren konkurrieren konnte, denn wenn man auch ohne Sprungvorhersage so schnell ist wie andere bei perfekter Vorhersage, dann ist man bei sehr entscheidungsfreudigen Programmen im Vorteil.
>> Aber das ist ja heute (bei den meisten Controlern) genau so ! >> Die meisten Controler laufen bis ca 16..ca50 MHz, bei CPU <und> >> Speicher. >Und trotzdem sind Register meist immer noch wesentlich schneller. In der >Regel kann beim RAM (bzw. Cache) nur maximal ein Load oder Store pro >Takt ....... ja, gibt es, aber das sind schon eher spezialfälle und geht schon eher in Richtung Hochleistung. (Ein guter DSP kann noch weit mehr als 3 Werte in einem Takt laden, aber das ist meistens speziel auf bestimmte Anwendung zugeschnitten. Bei den meisten Controllern (schätze ca 85%) sind keine 2 Loads innerhalb 1 Takt möglich und auch gar nicht nötig........... weil die f immer höher geht und somit die gleiche (rel. einfache) Architektur autom. auch schneller wird. Somit lassen sich auch mit der gleichen (rel. einfachen) Architektur immer mehr Anwendungen "erschlagen". ...will nur sagen, der Markt bezahlt kein "Gimmik" im Controller, wenns für die Anwendung nicht unbedingt gebraucht wird. und die meisten kleinen und mittleren Controller werden fast nur noch "über den Preis" verkauft.
MCUA schrieb:
> ...will nur sagen, der Markt bezahlt kein "Gimmik" im Controller,
Wobei die Hersteller der Cortex-M3 basierenden Controller grad kräftig
dabei sind, solcherlei Gimmick frisch einzubauen. Weil man sich eben
auch im Controller-Sektor gerne durch MHz von der Konkurrenz absetzen
will, aber leider leider das Flash-Mem mit dem Tempo vom Core nicht
recht mithält. Und so finden sich immer komplexere Gimmicks zwischen
Flash und Core um nicht bei jedem Sprung längere Kaffeepausen einplanen
zu müssen. Aber wehe einer kommt und nennt das einen Cache - dann kauft
es wohl keiner mehr weil zu komplex. ;-)
MCUA schrieb:
> Und eine X86-CPU interessiert in der EmbeddedWelt so gut wie keinen.
So pauschal kann man das nicht wirklich sagen. Der 80186 z.B. wurde von
Intel selbst bis 2007 noch produziert, und andere Hersteller produzieren
den immer noch, und zwar bestimmt nicht für den PC-Markt ;-)
Oder z.B. die AMD Geode-Reihe.
Andreas
MCUA schrieb: > Und eine X86-CPU interessiert in der EmbeddedWelt so gut wie keinen. Im unteren und mittleren Sektor nicht mehr so richtig, aber Intel hatte mit den Atoms ursprünglich vor, den oberen Embedded Sektor nicht gänzlich ARM (und VIA) überlassen zu müssen. Dass man die heute eher als Triebwerke der Netbooks wahrnimmt hatte auch Intel überrascht.
>> Und eine X86-CPU interessiert in der EmbeddedWelt so gut wie keinen. >So pauschal kann man das nicht wirklich sagen...... Der 80186 ? Man kann wahrscheinlich die Firmen, die den noch einsetzen an ein paar Fingern abzählen. Dad ding ist zig Jahre alt, zu teuer und grottenschlecht, kein Mensch nimmt sowas für neue Designs. AMD Geode-Reihe ist auch X86er und hat auch die (bescheuerte) PC-Architektur, und wenn irgentwo in einem Gerät ein X86 zu sehen ist (also ab '286er oder höher) steckt fast IMMER ein PC (resp PC-Architektur) drin. Aber genau das will im embedd-bereich (der ja kostengünstig u. effinzient sein soll) keiner haben. Bei gleicher Leistung sind X86-cpus fast immer viel teurer als andere cpus (oder dsps). Und deshalb sind auch von allen weltweit verkauften CPUs nur ca 1% X86-CPUs!
MCUA schrieb: > Der 80186 ? Man kann wahrscheinlich die Firmen, die den noch einsetzen > an ein paar Fingern abzählen. Dad ding ist zig Jahre alt, zu teuer und > grottenschlecht, kein Mensch nimmt sowas für neue Designs. Offenbar ist der Bedarf aber immer noch gross genug, dass erst 2007 ein neuer Hersteller mit einem 80186-Derivat neu auf den Markt gekommen ist (http://www.innovasic.com/). Klar sind das hauptsächlich Legacy-Anwendungen, aber davon offenbar genug. > AMD Geode-Reihe ist auch X86er und hat auch die (bescheuerte) > PC-Architektur, und wenn irgentwo in einem Gerät ein X86 zu sehen ist > (also ab '286er oder höher) steckt fast IMMER ein PC (resp > PC-Architektur) drin. Logisch. Es setzt wohl niemand einen Geode ohne den zugehörigen Companion-Chip ein, und damit ist ja die PC-Architektur in ihren wesentlichen Teilen schon komplett (OK, RAM muss auch noch dazu). Aber wo ist denn deiner Meinung nach der grosse Unterschied (vom CPU-Kern mal abgesehen) zwischen einem x86 mit via PCI(-E) angebundener Peripherie, und einem MIPS- oder ARM-SoC mit PCI-Peripherie? Vieles was der PC-Architektur immer vorgeworfen wird sind Vorurteile aus längst vergangenen Zeiten. Selbst das alte Problem des (verhältnismässig) geringen IO-Durchsatzes hat sich spätestens mit PCIe inzwischen erledigt. Von der alten PC/AT-Architektur ist auf Ebene der Hardware heute nicht mehr viel übrig geblieben. Das bisschen Legacy-Kram (Real Mode nach dem Reset z.B.) wird heute nur noch beim Booten einmal kurz angefasst, und ist danach bis zum nächsten Reset nicht mehr relevant. > Aber genau das will im embedd-bereich (der ja kostengünstig u. > effinzient sein soll) keiner haben. Embedded heisst nicht immer klein. Juniper z.B. setzt für die Routing Engines in ihren Highend-Routern komplett auf x86-CPUs (natürlich mit einem Sack voll Spezial-ASICs), im SMP-Betrieb, mit mehreren GB RAM. Trotzdem ist das embedded. (Harte) Echtzeit ist bei der Anwendung nicht wirklich relevant. > Bei gleicher Leistung sind X86-cpus > fast immer viel teurer als andere cpus (oder dsps). Bis zu einem gewissen Punkt richtig, aber vor allem weil das untere Ende von x86 (von den Antiquitäten mal abgesehen) im Vergleich zu vielen anderen CPU-Architekturen schon ziemlich hoch liegt. Im Spitzenleistungsbereich (von Spezialanwendungen wie bei DSPs oder auch z.B. den Cell-Prozessoren mal abgesehen) bekommst du nirgendwo sonst soviel Rechenleistung für dein Geld. Nicht umsonst sind von den Top 10 der schnellsten Supercomputer ganze 7 x86-basiert (die restlichen drei sind PowerPC). > Und deshalb sind auch von allen weltweit verkauften CPUs nur ca 1% > X86-CPUs! Kunststück ;-) Zahlen habe ich zwar keine, aber 8bit-CPUs dürften da noch lange vorne bleiben. Interessant wäre allerdings mal ein Vergleich der verkauften Rechenleistung. Andreas
Die meisten x86er sind seit jeher nicht auf kostengünstige Fertigung bei nicht mehr ganz taufrischer Chiptech optimiert, sondern auf hohe Performance bei aktueller Chiptech des jeweiligen Herstellers. Das kann beispielsweise bedeuten, dass die Anzahl teurer Herstellungsschritte und Metallisierungsebenen eher dem entspricht was man sinnvoll herstellen kann, als dem, was man für billigen Masseneinsatz gerne machen würde. Und dass man dafür eine ganz bestimmte Herstellungstechnik benötigt, die anderswo nicht verfügbar ist. Ähnlich verhält es sich beim Stromverbrauch. Da war nicht der minimale Stromverbruch das Ziel, sondern maximale Performance bei in der jeweiligen Zeit tolerierbarem Stromverbrauch/Wärmeabfuhr (so ab 386 ungefähr). Wenn man also alte x86er für Embedded weiterleben lässt, dann liegt man bei den Fertigungskosten u.U. deutlich über dem, was die Konkurrenz bietet und verbraucht mehr Strom. Um mitziehen zu können reicht es folglich nicht, alte Designs in alter Technik weiterleben zu lassen, oder einfach nur zu schrumpfen. Man müsste sie mit anderem Designziel erheblich renovieren oder gar neu konstruieren (so geschehen beim Atom). Wenn man sie aber schon konstruieren muss, warum dann den ganzen historischen x86 Ballast mit rumschleppen? Binärkompatibilität ist ein PC-Dogma, das bei Controllern weniger rigide gesehen wird. Aus den gleichen Gründen eignen sich solche bestehenden x86-Cores nicht für die Integration in komplexere Chips, eignen sich nicht als lizenzierbare Cores. Dafür wurden sie nicht konstruiert. ARM andererseits ist als Hersteller exakt solcher Cores gross geworden und optimiert die Cores für kostengünstige bei vielen Chipfabs gängige Herstellungstechnik. Das war m.W. auch ein Problem der DEC StrongARMs und der sich später daraus entwickelnden Intel-ARM Schiene. Als schnelle Prozessoren in klassischer Konfiguration entstanden eigneten sie sich nicht für Onchip-Integration zusammen mit allerlei I/O und was der Kunde sonst so benötigte. So findet man bei den PowerPCs daher völlig getrennte Entwicklungslinien für klassische Prozessorchips einerseits und Mikrocontroller andererseits.
Also x86er auf Performance? Nein, aber überrascht hat mich der elegante Übergang vom 8086 zum 80286. Ganz so, als ob Intel beim 8086 bereits das Design des 80286 im Kopf hatte, und nur das damals realisierbare implementiert hatten, im Wissen, daß die Technik in ein paar Jahren das ganze Konzept umzusetzen erlaubt. Denn der 80286 war ein single chip Bourroughs 5500. Leider hat man ein bit vergessen, das dirty bit in der Segmentbeschreibung, das hat die virtuelle Speicherverwaltung ausgebremst. Der Übergang zum 80386 war dann jedoch extrem unelegant, man sieht es daran daß 16 bit Apps nicht problemlos neben 32 bit Apps liefen, sondern (unter Windows) Thunks benötigten, im Endeffekt neu geschrieben werden mussten.
@ Andreas Ferber mal ehrlich, du glaubst doch selbst nicht dass dieses olle ding 80186 in irgent einer Art für neue Designs interessant ist. Also warum darüber reden ? Und ob innovasic im nächsten Jahren ds weitermacht weiss auch keiner. Jedenfalls beliefert innovasic keine Firmen, die neue Geräte entwickeln. -------------------- Zu X86: Es gibt doch überhaupt keine X86Controller, die für embed interessant sind ! Und wenn, dann sind PCs! (oder 80186, ausgestorben, oder EX386, ausgestorben) Und ich häng mir in mein System nicht olles Zeugs wie PC rein. Mir wird allein schon schlecht wenn ich die INT-Archit vom PC ansehe. Auch die Adr-aufteilung ist eine Katastophe. Was sollen Segm-Reg? Register-Fenster f. Floating-unit sind auch grässlich. Gut, wenn jemand Grossrechner baut, kann er evtl X86, wegen sehr hoher möglicher Leistung nehmen.(muss auch dann mit den Altertümern in der CPU leben) Glaube aber eher nicht, dass es tausende Firmen gibt, die Grossrechner bauen. Der einigste Grund (und wirklich der einzigste!!!) warum es X86 überhaupt noch gibt, ist, weil es IBM in den PC rein gesetzt hat (und die Anwender es weiterhin nutzen wollten). Und dass weil die CPU besonders schlecht war, damit sich IBM nicht selbst Konkurenz machen musste. Wäre der PC-markt nicht da (gewesen), wäre X86 schon lange verschwunden!! Firmen hatten in den 80ern massenweise 68k-CPUs "nachgeahmt", aber kein einziger hat auf X86 gesetzt. Und auch das ist ein Grund, weshalb es X86 nur gibt, wenn es was mit PC zu tun hat (von wenige Ausnahmen abgesehen) Und man baut ein Gerät nicht um Rechenleistung zu haben, sondern man sucht einen Baustein für ein Gerät, dass die passende Rechenleistung hat. Und den findet man immer ausserhalb X86. bspweise ist auch Blackfin, Coldfire, oder SH2,SH3 sehr leistungsfähig, und die Chips kosten weit weniger als bei X86. und wenn Leistung nicht reicht sollte, kann man immer noch mehrere DSPs zus. einsetzen, dann ist auch mehr Leistung drin, als bei bei X86. und selbst dann wird es noch günstiger. und schlisslich kann man ja noch -wenn man will- 500 ALU-Einheiten in FPGA reinbauen. davon träumt dann ein Pentium. Die Frage, ob man einen X86 für embed (<>PC) einsetzen sollte, stellt sich also gar nicht, da es schlichtweg überhaupt keine Controller gibt! Und wenn X86 DIE Architektur wäre, würden fast alle neu hergestellten CPUs so heissen, aber das genaue Gegenteil ist der Fall. (nur ca 1%, diese Zahl alleine sagt schon alles) Hinzu kommt noch, dass man bei Intel nicht weiss, ob es den Baustin morgen überhaupt noch gibt. (Bsp intel-risc wurden von heut auf morgen abgekündigt, weshalb viele Firmen Intel "verflucht" haben. --------- Ja, bei PowerPC ist das total anders. Da gibt es ein grosses Spectrum an Anwendungen, vom Desktop übers Automobil bis in die Maschinensteuerungen. Motorola hat halt mit PowerPC eine ähnl. Markt-Schema gefahren, wie mit 68K. Und ein Teil des Befehlssatzes vom 68k gibts noch im Coldfire - auch interessanter Controller.
MaWin schrieb: > Nein, aber überrascht hat mich der elegante Übergang vom 8086 zum 80286. > Ganz so, als ob Intel beim 8086 bereits das Design des 80286 im Kopf > hatte Bei der Entwicklung des 8086 hatte Intel eher das grandiose alles erschlagende Design des iAPX432 im Auge, mit dem 8086 als zeitweiligem Zwischenschritt um die alten 8080-Kunden glücklich zu machen. Nur erwies sich der 432 als nacktes Desaster und der 8088 dank IBM als Erfolgsmodell. Also hat man dort einfach weiter gemacht. Dass Intel damals nicht weiter dachte als bis zu nächsten Laternenpfahl beweist eben die Segmentierung der 286. Jeder halbwegs vernünftig denkende Mensch hätte, wenn der Gedanke an die Zukunft eine Rolle spielt, bei der Segmentierung daran gedacht, dass man in der nächsten Generation gern Caches für die Segmentdescriptoren einbauen würde um die nicht jedesmal aus dem Speicher fischen zumüssen, bloss weil ES zwischen 2 Werten pendelt. Also auch Flush-Befehle wenn man mal am Descriptor was dreht. Nicht so Intel. Hat man vergessen. Und so waren echte Descriptor-Caches für's Erste ausgeschlossen. Dieser Dummheit hat dazu geführt, dass sich dank exzessiver Ladezeiten die Segmentierung nicht dauerhaft durchsetzte und hat Intel zweitens beim PentiumPro einen saftigen Tritt in den Achtersteven verpasst, weil u.A. auch deshalb Win95 damit nicht gut zurecht kam. Und Intel gezwungen war, im Pentium II eine aufwendige Schnüffel-Logik zu implementieren, die Descriptor-Modifikationen spitz kriegt. > Der Übergang zum 80386 war dann jedoch extrem unelegant, man sieht es > daran daß 16 bit Apps nicht problemlos neben 32 bit Apps liefen, sondern > (unter Windows) Thunks benötigten, im Endeffekt neu geschrieben werden > mussten. Lustigerweise haben Microsoft und IBM mit OS/2 ein ebensolches Wunderwerk vollbracht. Gleich zweimal. Allerdings nicht wirklich elegant, wenn auch irgendwie eindrucksvoll. Zunächst in V1.x, als das System mitsamt Device-Drivern mal im Real-Mode und mal im Protected-Mode lief, die Device-Driver also bimodal arbeiten mussten (vorzugsweise so, dass sie es garnicht wissen müssen worin sie grad arbeiten). Dass Intel eine Umschaltung zurück in den Real-Mode überhaupt nicht vorgesehen hatte, das hat dabei nicht gestört. Man hatte ja den Tastaturcontroller, der einen Reset auslösen konnte, und man hatte (irgendwann) den Triple-Fault, der dies deutlich schneller zuwege brachte. Danach in V2,x aufwärts, als das System eine kunterbunte Mischung aus 16- und 32-Bit Komponenten war und der Adressraum von 32-Bit-Programmen so mit 64KB Segmenten zugepflastert wurde, dass man 512MB sowohl linear als auch segmentiert adressieren konnte, man musste nur die Pointer ein kleines bischen umrechnen. Deshalb war denn auch bei 512MB Prozessadressraum Schluss.
> Dass Intel damals nicht weiter dachte als bis zu nächsten Laternenpfahl Das möchte ich stark bezweifeln, siehe vorherigen Beitrag. > dass sich dank exzessiver Ladezeiten die Segmentierung nicht dauerhaft > durchsetzte Ja, und durch den kleinen Bug im CPU-Design glaubt nun die halbe Menschheit (oder doch die ganze? Nun, zumindest die ganz dummen) Segmentierung wäre blöde. Dabei ist es die sinnvollste Form der Speicherverwaltung. > Also auch Flush-Befehle wenn man mal am Descriptor was dreht. Natürlich nicht, niemals, so was muss die CPU von selbst bemerken. Dirty bit, sonst wüdre es ja inkonsistent, wenn man es mal vergisst. > iAPX432 Tja, damals, fand ich das toll (obwohl ich überhaupt nicht verstand, wie die arbeiten sollte, aber es klang alles hochwissenschaftlich, eine objektorientierte CPU, erst heute weiss man warum die nicht performant war). Aber sie war so verschieden von der 80x86, daß klar ist, daß sie nicht Vorlage des 80286 war.
MaWin schrieb: > Das möchte ich stark bezweifeln, siehe vorherigen Beitrag. Intel selbst hat mehrfach versucht, vom x86 wegzukommen. Einmal stand (auch) IBM im Weg, einmal AMD. Grad heute las ich, das Microsoft einen entscheidenden Nagel in den Sarg von IA64 getrieben hat. > Tja, damals, fand ich das toll (obwohl ich überhaupt nicht verstand, wie > die arbeiten sollte, aber es klang alles hochwissenschaftlich, eine > objektorientierte CPU, Die 432 dürfte so einige Wälder in Form von Uni-Papieren abgeholzt haben. Mir blieb das allerdings erspart. > war). Aber sie war so verschieden von der 80x86, daß klar ist, daß sie > nicht Vorlage des 80286 war. So meinte ich das auch nicht. Intel selbst hatte bei der 8086 ursprünglich überhaupt keine ernsthafte Zukunft vorgesehen. Die sollte woanders stattfinden. Die 286 war Intels Notnagel, als sich 432 als unpraktikabel und 8088 als unerwartet erfolgreich erwies. Die Segmentierung für ein paar mehr Adressbits hatte man ja schon, nur der Inhalt musste sich ändern. Und dass die nicht so ganz auf Intels Mist gewachsen ist, sondern von einem fremden Baum gepflückt wurde, das hast du ja schon selber erwähnt.
>Bei der Entwicklung des 8086 hatte Intel eher das grandiose alles >erschlagende Design des iAPX432 im Auge, mit dem 8086 als zeitweiligem >Zwischenschritt um die alten 8080-Kunden glücklich zu machen. Nur erwies >sich der 432 als nacktes Desaster und der 8088 dank IBM als >Erfolgsmodell. Also hat man dort einfach weiter gemacht. Genau!!!! Der 8086 war nichts weiter als eine (katastophal) aufgebohrte Notlösung von älteren Bausteinen, die seinerseits ebenfalls schon eine aufgebohrte Notlösung waren, die seinerseits ebenfalls schon eine aufgebohrte Notlösung waren...u.s.w. Und nun sitzt dieser Schrott immer noch in den neuen Bausteinen. (Und !nur! wegen dieser (katastophal) aufgebohrten Notlösung sitzen da auch Segmentregister ) ALLE(!!) andere Hersteller haben sich NICHT solchen Unsinn gemacht, und ALLE(!!) anderen Hersteller haben auch keine Segmentregister ! Und wenn einer alleine meint auf der Autobahn richtig zu fahren, und tausende kommen ihm entgegen, dann ist der eine der Geisterfahrer, nicht die tausend anderen.
MaWin schrieb: > Ja, und durch den kleinen Bug im CPU-Design glaubt nun die halbe > Menschheit (oder doch die ganze? Nun, zumindest die ganz dummen) > Segmentierung wäre blöde. Dabei ist es die sinnvollste Form der > Speicherverwaltung. Mit einem Hang zur Fragmentierung und mit noch mehr zeitraubender Adressrechnung vor der Cache-Adressierung. Weshalb man heute mit einem Extratakt für Cachezugriff bestraft wird, wenn man sie verwendet. So richtig erschliesst sich mir der Charme von Segmentierung aus der Sichtweise von effizienter Mikroarchitektur jedenfalls nicht (aus der Sichtweise von Programmobjekten schon, aber dazu siehe 432). Also muss ich wohl doch zu den ganz dummen gehören.
MCUA schrieb: > ALLE(!!) andere Hersteller haben sich NICHT solchen Unsinn gemacht, und > ALLE(!!) anderen Hersteller haben auch keine Segmentregister ! Stimmt nicht ganz. Zilog ging den gleichen Weg und setzte mit der Z8000 auch auf Segmentierung. Allerdings besser als Intel, jedenfalls was die Segmentierung angeht. Das denen mittendrin der Chefdesigner davon lief und sie dummerweise auf Statemachines statt Microcode setzten (=> Entwicklungszeit) hat der Z8000 allerdings auch nicht geholfen.
>> ALLE(!!) andere Hersteller haben sich NICHT solchen Unsinn gemacht, und >> ALLE(!!) anderen Hersteller haben auch keine Segmentregister ! >Stimmt nicht ganz. Zilog ging den gleichen Weg ....... Ja, und Zilog-Mitarbeiter kamen von Intel ! (und Zilog wollte in Teilen kompatibel zu Intel bleiben !) Und wie bedeutend ist Zilog heute ?
Ach ja: IBMs Power und folglich PowerPC, in 32 wie in 64 Bits, hat ebenfalls Segmentierung. Wenn auch etwas anders, und mit etwas anderem Ziel.
MCUA schrieb: > Ja, und Zilog-Mitarbeiter kamen von Intel ! Yep, aber das war vor Z8000. Und mit Kompatibilität hatte die Segmentierungsidee nichts zu tun. Die Z8000 als Zielsystem für hingewürgt umgesetzte Z80-Programme ja, aber nicht die Segmentierung. > Und wie bedeutend ist Zilog heute ? Dank IBM so bedeutend, wie manche es Intel wünschen ;-). Die Z8000 hatte ihre Fehler, aber besser als 8086 war sie vom Konzept her allemal.
Apropos "Wunderwerk" 680xx, Laternenpfähle und die jeweilige Sichtweite: Die 68020 war ein veritables Desaster, wenn es darum geht, Befehle einigermassen schnell zu dekodieren. Auch bei Motorola hörte die Perspektive beim nächsten Laternenpfahl auf. Aber diese Krankheit, man könnte sie das VAX-Fieber nennen, hatte damals viele erfasst (beispielsweise auch National Semiconductor [NS32000] und NEC [V70]). Intel blieb bei den x86ern einigermassen davon verschont, vielleicht hat dabei das 432-Desaster geholfen. Bei 386er Code geht eine schnelle Befehlsdekodierung und -ausführung jedenfalls leichter als bei 68020-Code. Was Motorola später dazu brachte, manche der grossartigen Erfindungen wieder einzustampfen oder zumindest deren Verwendung zu bestrafen.
> So richtig erschliesst sich mir der Charme von Segmentierung aus > der Sichtweise von effizienter Mikroarchitektur jedenfalls nicht Na ja, Windows muss heute den Programmcode einer 2 mal verwendeten DLL doppelt in den Speicher mappen und beide Speicherkopien nach dem Laden auch noch unterschiedlich modifizieren, nur weil keine Segmente der CPU mehr unterstützen, und versaut sich damit die virtuelle Speicherverwaltung. Unter Win16 war das noch hochelegant, Zugriffsschutz ist auch besser implementierbar. Fragmentierung ist nicht wirklich ein Problem, wenn der virtuelle Adressraum gross genug ist (was er erschreckenderweise nicht mal mit 48 bit ist, aber nun haben wir 64 bit...).
MCUA schrieb: > Nein, Register sind keine Klimmzüge, aber viele andere Ausführungs- und > Steuer-einheuten -bsp Cacheverwaltung, mehrere ALUs, Registerrenaming, > Sprungvorhersage- bei Prozessoren >= 200 MHz oder mehr, sind Klimmzüge > (die auch viel Geld kosten), die man bei einem 50MHz-Prozessor heute > nicht mehr braucht, weil der Speicher da genau so schnell ist wie > Register, und die Rechenleistung auch so schlichtweg ausreicht. Nö. Schau dir einen modernen Mikrocontroller an. Beispiel LPC21xx von NXP. Busbreite: Der Flash ist viel breiter als die CPU, weil er erheblich langsamer ist. Soweit ich weiß, haben sie das sogar patentiert. > > Und eine X86-CPU interessiert in der EmbeddedWelt so gut wie keinen. Auch falsch. 386EX lief in riesigen Stückzahlen. Ich selbst mußte mich mit dem Ding rumärgern.
MaWin schrieb: > Also x86er auf Performance? > > Nein, aber überrascht hat mich der elegante Übergang vom 8086 zum 80286. > Ganz so, als ob Intel beim 8086 bereits das Design des 80286 im Kopf > hatte, und nur das damals realisierbare implementiert hatten, im Wissen, > daß die Technik in ein paar Jahren das ganze Konzept umzusetzen erlaubt. > Ja, hatten sie. Irgendwo hatte ich dazu mal was gelesen. Sie mußten Features wegen zu hoher Integrationsanforderungen herausnehmen.
Andreas Ferber schrieb: > Aber wo ist denn deiner Meinung nach der grosse Unterschied (vom > CPU-Kern mal abgesehen) zwischen einem x86 mit via PCI(-E) angebundener > Peripherie, und einem MIPS- oder ARM-SoC mit PCI-Peripherie? Das Anhängsel "-SoC". Ein typischer x86 muss den größten Teil seiner Peripheriekommunikation über eine North Bridge (System Controller Hub im Fall von Atom) abwickeln, die dann über PCIe die eigentliche Peripherie Ansteuert. Das kostet Latenzzeit, und, da externer Buszugriff, viel Strom. Durch die notwendigerweise hohe Geschwindigkeit des FSB, wird das PCB Layout erschwert. Mit neueren Atom Varianten wird zwar mehr und mehr auf dem Chip integriert, aber viele Dinge sind eben immer noch extern angeflanscht. -- Marcus
>Nö. Schau dir einen modernen Mikrocontroller an. Beispiel LPC21xx von >NXP. Busbreite: Der Flash ist viel breiter als die CPU, weil er >erheblich langsamer ist. Soweit ich weiß, haben sie das sogar >patentiert. Achso, der Controller ist so gut, weil das Flash so schlecht ist ? Dann ist der Controller vielleicht neu, aber nicht modern und nicht gut. Gute Controller gehen bis 100MHz, und selbstverständlich geht das Flash auch bis 100MHz, sonst machts -wegen immer vorhandener Branches- wenig Sinn. ---------------------------- >> Und eine X86-CPU interessiert in der EmbeddedWelt so gut wie keinen. >Auch falsch. 386EX lief in riesigen Stückzahlen. Ich selbst mußte mich >mit dem Ding rumärgern. (386EX ist uralt) Nenn mal <einen> X86-Controller (nicht PC-basierend), der für embeded interessant wäre! ---------------------------- >Fragmentierung ist nicht wirklich ein Problem, wenn der virtuelle >Adressraum gross genug ist nein ein Problem ist es dann nicht, aber dann brauchts auch (fast) keiner ---------------------------- >> Und wie bedeutend ist Zilog heute ? >Dank IBM so bedeutend, wie manche es Intel wünschen Zilog dümpelt daher !, ist nichtmal unter den top 20 der HalbleiterHerstellern !, und auch im ControllerMarkt weit abgeschlagen!.
>Die 68020 war ein veritables Desaster, wenn es darum geht, Befehle >einigermassen schnell zu dekodieren. ich denke dass die op-struktur des Befehlssatzes und das CPU-Registermodell sehr gut und efizient war (bzw ist) Und der Coldfire (max ca 260MHz) kann heute (noch) sehr viele Befehle des 68K sehr schnell abarbeiten. >Auch bei Motorola hörte die Perspektive beim nächsten Laternenpfahl auf. nicht beim Programmiermodel
MCUA schrieb: > Gute Controller gehen bis 100MHz, und selbstverständlich geht das Flash > auch bis 100MHz Der Flash-Zugriff geht mit 100MHz (bei den LPC1700, nicht den LPC2000) weil er 5 Takte dauert. Damit der Controller darob nicht verhungert ist ein Prefetcher und hinreichend Bandbreite vorhanden, und damit er nicht bei jedem Sprung trotzdem ins Bodenlose fällt ist auch ein kleiner Cache dazwischen. Das dürfte beim angekündigten STM32 mit 120MHz ähnlich aussehen, zumal ST beim STR9 schon Erfahrung mit solchen Problemen gesammelt und es im ersten Anlauf zu dünn geriet (in der A-Version erheblich nachgebessert).
MCUA schrieb: > ich denke dass die op-struktur des Befehlssatzes und das > CPU-Registermodell sehr gut und efizient war (bzw ist) Eine Befehlcodierung, bei der die Länge eines Befehls nicht durch Dekodierung der der ersten 1-2 Worte ermittelbar ist, taugt schlecht für schnelle Dekodierung. Beim Original, der 68000, war's ok. Ging alles aus dem ersten Wort hervor. Mit der 68020 bestimmten jedoch Bits im Indexwort die Codierungslänge der Adressierungsart. Die Position des zweiten Indexwortes eines MOVE-Befehls hing nun von der sehr variablen Länge der Codierung ersten Operanden ab. Unschön sowas, verkompliziert die Ermittlung der Befehlslänge ungemein und erschwert superskalare Dekodierung erheblich. Dazu kommt, dass speicherindirekte Adressierungsarten ziemliches Teufelszeug sind, was den effizienten Ablauf der Ausführung von Befehlen in einem gepipelineten Prozessor angeht. Die Entwickler der superskalaren 68060 werden über die Übertreibungen der 68020 ziemlich geflucht haben. Ich glaube sie waren schon anno 68040 nicht mehr sehr glücklich darüber. > Und der Coldfire (max ca 260MHz) kann heute (noch) sehr viele Befehle > des 68K sehr schnell abarbeiten. Klar doch. Da war dieser ganze Spuk ja auch wieder radikal rausgeflogen. Die einzige Adressierungserweiterung der 68020, die wirklich Sinn ergab, war die völlig unproblematische Skalierung des Indexregisters. Der Rest war Unsinn.
MCUA schrieb: >>Auch bei Motorola hörte die Perspektive beim nächsten Laternenpfahl auf. > nicht beim Programmiermodel Soso... Die Bitbefehle erwiesen sich als eher kurzsichtig geplant. Wenn man die Bytes von links nach rechts und die Bits von rechts nach links numeriert, dann landet man bei Bitfeldern in Teufels Küche. Weshalb die Bitfeldbefehle der 68020 die Bits in umgekehrter Richtung numerierten wie die Einzelbitbefehle der 68000 und es in logischer Konsequenz neue Einzelbitbefehle gab, die ihre Bits andersrum numerierten als die alten. Planerische Weitsicht geht anders. Wenn man die Bytes von links nach rechts numeriert, dann tut man gut daran, dies auch bei den Bits zu tun (z.B. TI990 und wohl alle IBMs inklusive PowerPC). Das sieht allerdings anfangs etwas komisch aus.
zu NXP-LPC17... >> Gute Controller gehen bis 100MHz, und selbstverständlich geht das Flash >> auch bis 100MHz >Der Flash-Zugriff geht mit 100MHz ... Da bin ich mir sicher. Es könnte sein, dass das Flash langsamer ist, nur dass mehr auf einmal gelesen wird. Im Datenblatt habe keine genauen Angaben zur Geschwindigk des Flashs gefunden, bzw hat NXP die dort verschwiegen. das gehört normal aber dort rein. >Planerische Weitsicht geht anders. Ja nachher ist man immer schlauer. >..dann landet man bei Bitfeldern in Teufels Küche. nicht wenn mans auf 1 Byte bezieht
>Soso... Die Bitbefehle erwiesen sich als eher kurzsichtig geplant.
68000, 68020,... waren noch keine Controller, wie sie heute Standard
sind. Es waren nackte CPUs, die sich sehr elegant (!) programmieren
ließen.
Um auch 'mal etwas Positives dazu zu sagen :-)
MCUA schrieb: > Im Datenblatt habe keine genauen > Angaben zur Geschwindigk des Flashs gefunden, bzw hat NXP die dort > verschwiegen. das gehört normal aber dort rein. Steht sehr wohl irgendwo drin. Ab wieviele MHz wieviele Takte konfiguriert werden müssen. Gelesen werden wahlweise 16 Bytes oder 8 Bytes am Stück. >>Planerische Weitsicht geht anders. > Ja nachher ist man immer schlauer. Weshalb ich ein paar erwähnte, dir vorher schlauer waren. Die IBM360 gab es schon ein kleines Weilchen vor der 68000. >>..dann landet man bei Bitfeldern in Teufels Küche. > nicht wenn mans auf 1 Byte bezieht Yep, aber nur wenn deine Bitfelder keine Bytegrenzen überschreiten dürfen. Aber genau das wird davon üblicherweise verlangt. Ich meine auch, dass sie sogar 32-Bit-Wortgrenzen überschreiten dürfen. Und da wird die Numerierung der Bits im Bitfeld wirklich spassig. Es hat schon seinen Grund, weshalb Motorola genau zu diesem Zeitpunkt eine Kehrtwendung vollzog.
Tropenhitze schrieb:
> Um auch 'mal etwas Positives dazu zu sagen :-)
In diesem Thread geht es m.W. nicht speziell um Controller. Die
Anfangsfrage bezieht sich allgemein auf Rechnerarchitektur.
Ich will hier niemandem seine Lieblinge streitig machen. Nur ein bischen
den Lack abkratzen. ;-)
>Steht sehr wohl irgendwo drin. Ab wieviele MHz wieviele Takte >konfiguriert werden müssen. Genau das würde zeigen, dass das Flash nicht mir der vollen Geschw läuft.
MCUA schrieb: > Genau das würde zeigen, dass das Flash nicht mir der vollen Geschw > läuft. Mit vollem Takt ja, aber nicht mit einem Zugriff pro Takt und auch nicht gepipelined. Der Durchsatz ist aufgrund der Breite des Zugriffs ausreichend, aber es muss gewartet werden. Der Rest ist ein bischen Definitionssache oder Sprachspiel. Der Cache eines K7-K10 läuft mit vollem Takt und ist voll gepipelined, kommt aber auch erst nach 3 Takten zu Potte. Ist das nun volle Geschwindigkeit oder Drittel-Geschwindigkeit? Bei Atmels SAM7 führt der für vollen Takt nötige Waitstate zusammen mit mangelnder Bandbreite (4 Bytes) jedoch dazu, dass diesen Maschinchen bei ARM-Codierung die Luft ausgeht und sie mit Thumb-Code schneller sind. Philips/NXP hatte ins Flash-Interface schon von Anfang an deutlich mehr investiert.
>> Genau das würde zeigen, dass das Flash nicht mir der vollen Geschw >> läuft. >Mit vollem Takt ja, aber nicht mit einem Zugriff pro Takt und auch nicht >gepipelined. Der Durchsatz ist aufgrund der Breite des Zugriffs >ausreichend, aber es muss gewartet werden. Was bringen volle Takte, wenn sie "nebendran" laufen ? Also, der Flash ist viel zu langsam und damit ist der Controller abgehakt. (Zugriffsbreite kann keine Geschwindigkeit ersetzen!)
Der Flash ist nunmal technologisch zeitlich begrenzt. Ich weiß nicht genau warum, vermute es sind keine Metallebenen sondern Poly-Si oder wie die das nennen. Das hat offensichtlich höhere Bahnwiderstände. Alternative wäre alles in schnelles teures RAM zu kopieren. Interessante Diskussion. Besser als die tausendste Fahrradlicht-Konstantstromquelle! Mal zu anderen Aspekten: Mir gefiel die I/O-Struktur der 8051 mit dem halboffenen o.C.-Treiber. Andere hassen sie.
MCUA schrieb: > Also, der Flash ist viel zu langsam und damit ist der Controller > abgehakt. Damit wirst du jenseits von ca. 30-40MHz keine rechte Freude mehr an Controllern haben und solltest schleunigst deinen PC auf einen 286 mit maximal ca. 8MHz "up"graden. Danach hatten nämlich alle das gleiche Problem. Als Kompromiss könnte ich dir noch den bereits erwähnten AMD K5 empfehlen. Das war der einzige x86, dessen Cache mit einem einzigen Takt auskam. Alle anderen x86-er benötig(t)en auch für den L1-Cache bereits 2-4 Takte > (Zugriffsbreite kann keine Geschwindigkeit ersetzen!) Ach... Praktisch die gesamte IT-Welt jenseits der 8/16-Bit Controller arbeitet nach exakt diesem Muster. Schnelle Caches drinnen und langsamen aber bandbreitenreichen Speicher mit Prefetch draussen. NXP macht das nicht anders.
PS: Einen hätte ich noch für dich, immerhin ARM7. Die Aduc7000 von Analog Devices haben keine konfigurierbaren Waitstates bis zu ihrem Limit von ~41MHz (ich vermute zwar, dass sie einen versteckten Waitstate bei nonseq-access drin haben, das gibt der ARM-Core von Haus aus her, aber sei's drum). Dafür sind die genau umgekehrt gewickelt. Kurze Zugriffszeit bei mieser Bandbreite, denn das Flash ist ulkigerweise nur 2 Bytes breit, d.h. ein ganzer ARM-Befehl braucht 2 Zugriffe. Wer die Dinger gebaut hat gehört eigentlich windelweich... aber dir müsste es gelegen kommen. Pro Flash-Zugriff nur ein Takt und volles Tempo bei Thumb-Code.
> Ach... Praktisch die gesamte IT-Welt jenseits der 8/16-Bit Controller
Du wolltest sagen: jenseits der bitseriellen 1 bit Controller.
>Was bringen volle Takte, wenn sie "nebendran" laufen ? Und wenn das Flash "nebendran" läuft läuft der ganze Controller "nebendran". >Alternative wäre alles in schnelles teures RAM zu kopieren. Alternative wäre, alles im (schnell genugen) Flash zu haben, weil viel günstiger. >Damit wirst du jenseits von ca. 30-40MHz keine rechte Freude mehr an >Controllern haben Falsch. Es gibt Controller, bei denen das Flash mit vollem (echten, nicht getrickstem) 100MHz-Takt läuft. also Zugr.zeit von 10ns (nicht 30ns). Also: total freier Zugriff auf jede beliebige Speicherstelle binnen 10ns! Und es werden sogar in naher Zukunft (von der gleichen Firma) sogar Flashs mit (echten, nicht getrickstem) 200MHz-Takt erhältlich sein. >> (Zugriffsbreite kann keine Geschwindigkeit ersetzen!) >Ach... Praktisch die gesamte IT-Welt jenseits der 8/16-Bit Controller >arbeitet nach exakt diesem Muster. Schnelle Caches drinnen und langsamen >aber bandbreitenreichen Speicher mit Prefetch draussen. NXP macht das >nicht anders. Ja, die versuchen es (!!!), mehr auch nicht. Es ist total unmöglich mit breitem langsamen Speicher einen schnellen Speicher zu ersetzen. Da könnte man ja gleich bei einer 100 MHz-CPU einen 5 MHz Speicher nehmen, den mit der 20fachen Breite. Sowas kann nicht gehen. Denn es lässt sich nicht vermeiden, dass CPU etliche Branches machen muss. Lineare Befehls-Abarbeitung ist eine absolute Wunschvorstellung, das nur diejenigen Hersteller nennen, deren Speicher zu langsam ist. (aber ich gebe zu, dass man versuchen muss Klimmzüge zu machen, wenn man keinen schnelleren Flash hinbekommt, aber kein Klimmzug kann schnellen Speicher ersetzen)
MCUA schrieb: > Es gibt Controller, bei denen das Flash mit vollem (echten, > nicht getrickstem) 100MHz-Takt läuft. also Zugr.zeit von 10ns (nicht > 30ns). Welche sind das? Und warum machen das nur die? > Da könnte man ja gleich bei einer 100 MHz-CPU einen 5 MHz Speicher > nehmen, den mit der 20fachen Breite. Sowas kann nicht gehen. Exakt so arbeitet man aber, nur schaltet man Caches dazwischen. Es ist unstrittig, dass ein 5GHz-Rechner seine zig GB DRAM lieber durchweg mit 200ps Zugriffszeit als mit 50-200ns Zugriffszeit sehen würde, nur ist das in absehbarer Zeit schlichtweg unmöglich. Also begnügt man sich mit gestaffelt grösser und langsamer werdenden Caches zwischen schnellem Core und im Zugriff langsamem aber im Durchsatz relativ schnellen DRAM. > Denn es lässt sich nicht vermeiden, dass CPU etliche Branches machen > muss. Dazu gibt es ja die Caches. Manchmal hat man Pech, und dann ist eine längere Pause angesagt. IBMs RS64 haben solche Pausen für eine Thread-Umschaltung genutzt, entfernt ähnlich Intels Hyperthreading.
A. K. schrieb: > PS: Einen hätte ich noch für dich, immerhin ARM7. Die Aduc7000 von > Analog Devices haben keine konfigurierbaren Waitstates bis zu ihrem > Limit von ~41MHz (ich vermute zwar, dass sie einen versteckten Waitstate > bei nonseq-access drin haben, das gibt der ARM-Core von Haus aus her, > aber sei's drum). > > Dafür sind die genau umgekehrt gewickelt. Kurze Zugriffszeit bei mieser > Bandbreite, denn das Flash ist ulkigerweise nur 2 Bytes breit, d.h. ein > ganzer ARM-Befehl braucht 2 Zugriffe. Wer die Dinger gebaut hat gehört > eigentlich windelweich... aber dir müsste es gelegen kommen. Pro > Flash-Zugriff nur ein Takt und volles Tempo bei Thumb-Code. Luminary hatte die 1T-Flash-Technik von MoSys lizensiert, da dürfte es tatsächlich schneller sein. http://www.design-reuse.com/news/16281/mosys-fastest-embedded-flash-memory-luminary-micro.html Zum Ausgangsthema gibt's eine ganz brauchbare PhD Thesis PERL A Register-Less Processor http://www.cse.iitk.ac.in/~moona/students/9411161.pdf (inkl. Einflüsse der Caches, Cachegrößen, Caches-Misses etc.) Möchte man dann auch noch einen Prozessor, der nur einen einzigen Befehl kennt (Mem(b) := Mem(b)): Das gibt's von Maxim als MAXQ. http://en.wikipedia.org/wiki/Transport_triggered_architecture
Arc Net schrieb:
> kennt (Mem(b) := Mem(b)): Das gibt's von Maxim als MAXQ.
So gesehen sind es bei dem 2 Befehle:
Mem(a) := Mem(b)
Mem(a) := Const
(die Const lässt sich kumulieren, ist also nicht als Mem(b)
ausdrückbar).
>Welche sind das? u. a. z. B.: http://www.renesas.eu/_print_this_page_/products/mpumcu/reach_further/child_folder/sh_child_sh7216.jsp oder http://www.renesas.com/products/mpumcu/superh/sh7280/sh7286/sh7286_root.jsp >Und warum machen das nur die? Weil das auch ein bißchen teurer ist und ein Geizhals das nicht versteht.
RX(CISC)- u. SH(RISC)- Controller gehen bis 100MHz, auch das Flash.
Renesas ging schon immer eigene Wege. Aber dann ist eben bei 100MHz Schluß. Das ist bei den heutigen gewünschten Upgrades pro Jahr gerade mal 1-2 Jahre voraus. Und dann? Es gibt ein paar wenige Prozessoren mit tierisch viel RAM drauf.
MCUA schrieb: > Achso, der Controller ist so gut, weil das Flash so schlecht ist ? > Dann ist der Controller vielleicht neu, aber nicht modern und nicht gut. > Gute Controller gehen bis 100MHz, und selbstverständlich geht das Flash > auch bis 100MHz, sonst machts -wegen immer vorhandener Branches- wenig > Sinn. Quatsch! Stören tun die Waitstates nur wegen der nicht mehr möglichen Hard-Realtime, so wie es z.B. der Propeller-Chip vormacht. Wobei ich nicht so recht weiß, ob die Fähigkeit zum wirklich predektiven Zeitverhalten wirklich was bringt. Ich sortiere das momentan unter 'Werbung' ein. > > ---------------------------- > >>> Und eine X86-CPU interessiert in der EmbeddedWelt so gut wie keinen. >>Auch falsch. 386EX lief in riesigen Stückzahlen. Ich selbst mußte mich >>mit dem Ding rumärgern. > (386EX ist uralt) Ja, das ist gewünscht. Man kennt alle Bugs (hofft man) und es gibt genug Entwickler, die damit zurecht kommen. Firmen entscheiden oftmals recht wenig nach technischen Gesichtspunkten. In meinem konkreten Fall war es die Möglichkeit, einfach DOS aufzusetzen. Und da man sie im Lager hatte, hatte das nächste Projekt wieder eine, diesmal mit Linux. Aus dem genau gleichen Grund wurde dann auch ein extra i2c-Controller eingebaut, obwohl jeder modern denkende Entwickler den in Software realisiert. Und dann wurden anstatt einem Flash eben mehrere eingebaut. Rate mal warum? Wieder das Gleiche! würg würg würg > Nenn mal <einen> X86-Controller (nicht PC-basierend), der für embeded > interessant wäre! > BECK IPC z.B. Nicht das ich es so toll fände. Fällt mir aber gerade ein. > >>> Und wie bedeutend ist Zilog heute ? >>Dank IBM so bedeutend, wie manche es Intel wünschen > Zilog dümpelt daher !, ist nichtmal unter den top 20 der > HalbleiterHerstellern !, und auch im ControllerMarkt weit abgeschlagen!. Zilog ist in einigen Nischen noch groß, z.B. Z8 TV-Fernbedienungen und so ein Kram. Und ihre SCC z.B. findet man auch überall.
Im Web steht zwar die Aussage: "single-cycle embedded flash memory
eliminates the need to execute from RAM.".
Im Manual vom SH7286 steht jedoch:
ROM cache Instruction/data separation system
• Instruction prefetch cache: Full/set associative
• Instruction prefetch miss cache: Full/set associative
• Data cache: Full/set associative
• Line size: 16 bytes
• Hardware prefetch function (continuous/branch prefetch)
Wenn ich mal raten darf: Das ist ein normales Flash, vielleicht
gepipelined ("single cycle"), mit Cache vorneweg.
Marcus Harnisch schrieb: >> Aber wo ist denn deiner Meinung nach der grosse Unterschied (vom >> CPU-Kern mal abgesehen) zwischen einem x86 mit via PCI(-E) angebundener >> Peripherie, und einem MIPS- oder ARM-SoC mit PCI-Peripherie? > Das Anhängsel "-SoC". Ein typischer x86 muss den größten Teil seiner > Peripheriekommunikation über eine North Bridge (/System Controller Hub/ > im Fall von Atom) abwickeln, die dann über PCIe die eigentliche > Peripherie Ansteuert. Das kostet Latenzzeit, und, da externer > Buszugriff, viel Strom. Durch die notwendigerweise hohe Geschwindigkeit > des FSB, wird das PCB Layout erschwert. Ja. MCUA beschwerte sich aber über Dinge wie das Interrupthandling etc., also die Architektur aus OS-Sicht. Auf dieser Ebene besteht aber kein grundlegender Unterschied mehr. Der x86-Legacy-Kram wird beim Booten einmal wegkonfiguriert, und ist danach nicht mehr relevant. Die Altlasten machen x86 vielleicht eher wenig tauglich für Mikrocontroller, da sie Chip-Platz verbrauchen, obwohl das de fakto eigentlich keiner mehr benutzt. Für's OS wird die Architektur dadurch aber nicht schlechter. Andreas
>Wenn ich mal raten darf: Das ist ein normales Flash, vielleicht >gepipelined ("single cycle"), mit Cache vorneweg. Falsch: 0 Punkte! Programme können auch im externen SDRAM und Burst-ROM liegen. Die sind nicht so schnell wie der interne Speicher; dafür ist dann ein Cache nicht schlecht. Kapitel 9.5.9 Die Teile sind richtig schnell; der SH7286 hat zudem zwei Ausführungseinheiten.
Tropenhitze schrieb: >>Wenn ich mal raten darf: Das ist ein normales Flash, vielleicht >>gepipelined ("single cycle"), mit Cache vorneweg. > > Falsch: 0 Punkte! Solche Sicherheit, basierend einzig auf den zwei Worten "single cycle" ist mutig. > Programme können auch im externen SDRAM und Burst-ROM liegen. Die sind > nicht so schnell wie der interne Speicher; dafür ist dann ein Cache > nicht schlecht. Dass man für externes ROM einen Cache brauchen kann beweist dir, dass man intern keinen verwendet? Ich habe auch eine Seite zu bieten: Das Blockdiagramm von 26.2.1 zeigt, dass das interne Flash am den ROM Cache Bussen hängt.
>Renesas ging schon immer eigene Wege. Aber dann ist eben bei 100MHz >Schluß. Das ist bei den heutigen gewünschten Upgrades pro Jahr gerade >mal 1-2 Jahre voraus. @Abdul K. Ich habe mal den SH7216 angesehen. Der schleicht mit 200MHz und zwei (sicherlich überflüssigen) Ausführungseinheiten nur bis max. 480 Mips. Internes FLASH, RAM, FPU und viel I/O - alles auf einem Chip ohne externe Zusätze. >Und dann? Wenn das alle Hersteller in zwei Jahren bieten, freuen wir uns sehr :-)
MCUA schrieb: > Und ich häng mir in mein System nicht olles Zeugs wie PC rein. > Mir wird allein schon schlecht wenn ich die INT-Archit vom PC ansehe. > Auch die Adr-aufteilung ist eine Katastophe. Was sollen Segm-Reg? > Register-Fenster f. Floating-unit sind auch grässlich. Du solltest deine Vorurteile ab und an mal updaten. Die alten Probleme mit den Interrupts sind kein wirkliches Thema mehr, seit der SMP-Pentium den APIC eingeführt hat. Segment-Register müssen vom OS noch an ein, zwei Stellen berücksichtigt werden (Switch zwischen Kernel- und Usermode), in Anwendungen kann man die getrost einfach ignorieren. Der Register-Stack (Register Window ist was anderes, das kennt z.B. SPARC) in der FPU ist seit SSE2 (Pentium 4, Athlon 64) meist nicht mehr relevant. Ausserdem kann man mit dem Registerstack in Assembler durchaus elegant programmieren, nur Compiler tun sich damit ggf. leider ein wenig schwer. > Der einigste Grund (und wirklich der einzigste!!!) warum es X86 > überhaupt noch gibt, ist, weil es IBM in den PC rein gesetzt hat (und > die Anwender es weiterhin nutzen wollten). Und dass weil die CPU > besonders schlecht war, damit sich IBM nicht selbst Konkurenz machen > musste. > Wäre der PC-markt nicht da (gewesen), wäre X86 schon lange > verschwunden!! Und wenn die Sonne kälter wäre, hätten Sonnencremehersteller ein Problem. Was für ein Argument. Fakt ist nunmal, dass x86 schon hundertmal totgesagt wurde, und trotzdem nicht nur immer noch lebt, sondern ausserdem insbesondere in der Leistung immer wieder neue Maßstäbe setzt. Für Spezialanwendungen (DSPs, Cell etc.) findet man ggf. auch was schnelleres, für General Purpose kann aber derzeit einfach niemand x86(-64) das Wasser reichen. Dein Argument funktioniert übrigens auch andersrum: wäre der Mikrocontrollermarkt nicht da (gewesen), dann wären 8051, 8048, ARM, MIPS und zig andere schon lange verschwunden. > Und man baut ein Gerät nicht um Rechenleistung zu haben, sondern man > sucht einen Baustein für ein Gerät, dass die passende Rechenleistung > hat. Klar. Trotzdem gibt es Embedded-Anwendungen, wo man (fast) garnicht genug Rechenleistung haben kann. Das Beispiel mit den Routern hatte ich schon genannt. Wenn du mit Routing-Tabellen im Gigabyte-Bereich hantierst, dazu dann noch in deinen Routingprotokollen Konvergenzzeiten im (unteren) Millisekundenbereich erreichen willst, Netzwerkmonitoring-Aufgaben etcpp., dann brauchst du eben Rechenleistung ohne Ende. Das macht das System aber nicht weniger Embedded. Dazu kommt, dass man bei sowas nicht bei Adam und Eva mit der Programmierung anfangen will. Dementsprechend ist es von Vorteil, wenn man als Grundlage ein vorhandenes Betriebssystem benutzen kann, wo Scheduler, Memory Management etc. schon fertig sind. Bei Juniper ist die Basis z.B. FreeBSD. > Und den findet man immer ausserhalb X86. > bspweise ist auch Blackfin, Coldfire, oder SH2,SH3 sehr leistungsfähig, > und die Chips kosten weit weniger als bei X86. Es gibt auch Embedded-Anwendungen (Highend-Router...), wo der Preis im wesentlichen durch den Entwicklungsaufwand entsteht und nicht durch die Fertigungskosten. > und wenn Leistung nicht reicht sollte, kann man immer noch mehrere DSPs > zus. einsetzen, dann ist auch mehr Leistung drin, als bei bei X86. > und selbst dann wird es noch günstiger. > und schlisslich kann man ja noch -wenn man will- 500 ALU-Einheiten in > FPGA reinbauen. davon träumt dann ein Pentium. Wenn man immer wieder stupide die gleichen Operationen ausführen will kann man das schneller haben, keine Frage. Aber implementier doch mal einen kompletten Netzwerkstack, mit einem ganzen Sack voll Anwendungsprotokolle auf einem FPGA. Viel Spass. Andreas
Tropenhitze schrieb: >>Renesas ging schon immer eigene Wege. Aber dann ist eben bei 100MHz >>Schluß. Das ist bei den heutigen gewünschten Upgrades pro Jahr gerade >>mal 1-2 Jahre voraus. > > @Abdul K. > Ich habe mal den SH7216 angesehen. Der schleicht mit 200MHz und zwei > (sicherlich überflüssigen) Ausführungseinheiten nur bis max. 480 Mips. > Internes FLASH, RAM, FPU und viel I/O - alles auf einem Chip ohne > externe Zusätze. Deine Polemik interessiert mich nicht. Bitte nur Fakten und die so, das alle was davon haben. > >>Und dann? > Wenn das alle Hersteller in zwei Jahren bieten, freuen wir uns sehr :-) Die Diskussion über den optimalen Controller kommt ja erst noch. Das hier war erst die Einleitung...
>Solche Sicherheit, basierend einzig auf den zwei Worten "single cycle" >ist mutig. Dem Mutigen gehört die Welt!
Tropenhitze schrieb: >>Solche Sicherheit, basierend einzig auf den zwei Worten "single cycle" >>ist mutig. > > Dem Mutigen gehört die Welt! Ja, aber nur wenn sie sich rechtzeitig noch Fortpflanzen konnten.
Tropenhitze schrieb: > Die Teile sind richtig schnell; der SH7286 hat zudem zwei > Ausführungseinheiten. Das bestreite ich nicht. Ein 4-Cycle Flash ROM mit etwas Cache und Prefetching kann statistisch einen Speicher mit einer Zugriffszeit von ein bischen über einem Takt einbringen. Mehr will man i.d.R. nicht.
http://elmicro.com/files/renesas/monos_flash_ewc_2008_for_proceedings.pdf Bevor wir wieder zu laut werden :-)
MCUA schrieb: > Und wenn X86 DIE Architektur wäre, würden fast alle neu hergestellten > CPUs so heissen, aber das genaue Gegenteil ist der Fall. (nur ca 1%, > diese Zahl alleine sagt schon alles) Ich hätte BTW eher auf noch deutlich weniger als 1% getippt. Alleine schon in und um einen normalen heutigen PC findet man doch heute locker eine deutlich zwei- oder sogar dreistellige Zahl von Mikrocontrollern anderer Architekturen (und sei es ein ARM in einer SD-Flashkarte). Die Zahl zeigt aber vor allem eins: x86 skaliert eben nicht nach unten. Sonst garnichts, insbesondere nichts darüber, ob eine Architektur "gut" oder "schlecht" ist. Andreas
Andreas Ferber schrieb: > eine deutlich zwei- oder sogar dreistellige Zahl von Mikrocontrollern > anderer Architekturen (und sei es ein ARM in einer SD-Flashkarte). Oder ein 8051 in einem SSD-Controller. Kein Witz, leider. Der Phison Chip PS3006, der diverse SSDs der eeePCs antreibt, hat den drin: "Build-In 1T RISC uP8051".
Tropenhitze schrieb: > http://elmicro.com/files/renesas/monos_flash_ewc_2008_for_proceedings.pdf > > Bevor wir wieder zu laut werden :-) Gleich in der Überschrift steht '10ns'. Der Kehrwert ist 100MHz, womit wir wieder bei den 100MHz aus meinen Post sind. Also was willst du damit sagen? - Der 8051 stirbt nie aus! Warum auch, er ist effizient und er besitzt einen respektablen Compiler dazu! Das ist auch ein wichtiger Punkt. Der Keil-C ist sowas von optimierend, das man es per Hand kaum besser machen könnte. Allenfalls wenn man die eigene Arbeitszeit schlicht ignoriert. Schon der 8048 tat sich schwer mit dem Ableben.
Abdul K. schrieb: > Der 8051 stirbt nie aus! Warum auch, er ist effizient und er besitzt > einen respektablen Compiler dazu! Kein Problem damit. Nur mit der Performance von dieser SSD, damit hatte ich schon eins. Vielleicht ist ein 8051 doch nicht ganz so ideal für Anwendungen, die hohen Durchsatz mit der Verwaltung etliche Byte breiter Blockadressen verbinden.
Der 8051 wird sofort ineffizient, wenn er großartig auf externen Speicher zugreifen muß. Die ganzen Konstrukte wie doppelter DPTR usw. taugen nix wirklich. Keil-C unterstützt z.B. direkt Banked-ROM. Als reiner Controller im Sinne einer Prozeßsteuerung aber ein guter Chip. Die Anwenderfirmen gehen halt oft seltsame Wege. Kenne den Fall, wo erst 8KB nötig waren und die Sache dann bei 256KB endete. Ohne C-Compiler wäre es gar nicht mehr händelbar gewesen.
> http://elmicro.com/files/renesas/monos_flash_ewc_2008_for_proceedings.pdf
Und das alles wegen CO2-Einsparung ?? (letzter Satz).
Man muß das nur oft genug wiederholen, dann glaubts jeder. Arbeitslosigkeit und Hunger ist nicht schlimm, produziert auch weniger CO2.
>Quatsch! Stören tun die Waitstates nur wegen ..... Nein. Waitstates stören fast immer, weils fast immer verlorene Zeit und vergeudete CPU-Leistung ist. >>>> Und eine X86-CPU interessiert in der EmbeddedWelt so gut wie keinen. >>>Auch falsch. 386EX lief in riesigen Stückzahlen. Ich selbst mußte mich >>>mit dem Ding rumärgern. >> (386EX ist uralt) >Ja, das ist gewünscht. Man kennt alle Bugs ...... Bei welchen Leuten schaffst du, dass die froh sind, Bugs hegen und pflegen zu dürfen ? >In meinem konkreten Fall war es die Möglichkeit, einfach DOS aufzusetzen. Aha. Dos ! geht das vielleicht mit PC ? >> Nenn mal <einen> X86-Controller (nicht PC-basierend), der für embeded >> interessant wäre! >BECK IPC z.B. Das ist ein PC !!! >Für's OS wird die Architektur dadurch aber nicht schlechter. Ja, es gibt aber etliche OS's, für alles mögliche. Das ist kein Grund für X86. Ausserdem ist das meiste von OS (ausser Scheduler) in Hichsp. gesch, so dass rel gut portierbar. nur kompatible PC sind 'Grund' für X86, (und evtl einige (extrem wenige) andere exotische Systeme.) >Dass man für externes ROM einen Cache brauchen kann beweist dir, dass >man intern keinen verwendet? Cache ist in dem Fall nur für draussen, nicht für drinnen. >> Wäre der PC-markt nicht da (gewesen), wäre X86 schon lange >> verschwunden!! >Und wenn die Sonne kälter wäre....... Ja das ist <DAS> Argument, das zeigt, das die X86er-Archit. im Grunde d-o-o-f ist! (weil immer nur (grässlich) aufgebohrt.) Denn der Markt (ohne PC) hätte diese doofe Archit. schon lange verschwinden lassen! Wegen der geforderten PC-Kompatibilität hätte man auch JEDE andere Archit. (erst recht 68k) wegen den kleinen Prozessgeometrien und möglichen 'Klimmzügen' auf Hochleistung trimmen können. selbst ein 6502 hätte man erweitern und hochtrimmen können (wenn man gewollt hätte und genug Aufwand reingesteckt hätte), wenn Kompatibilität gefordert wäre. Dann wäre heute vielleicht ein 6502XX eine Hochleistungs-CPU. Es war als (für Intel) nichts anderes als pures Glück, dass dad Ding in PC gesteckt wurde. (Aber Intel (bzw die Entwickler, die gekauft wurden) waren natürlich schon gut, dass die das grässliche Ding weiter hochgetrimmen haben können. Aber man kann jede Archit. hochtrimmen, auch wenn sie im Grunde grässlich ist. zu 8051: Ich kann NICHT EINEN EINZIGEN VORTEUL (mehr) finden, bei dieser CPU. Im Gegenteil. Die fast überall SCHLECHTER! Also warum drüber reden? Ich denke, die Leute die '51 heute noch einsetzen, haben einfach keine Lust sich verschiedene CPUs anzugucken, oder sie stellen nicht (mehr) die geringste Anforderung an die CPU, und benutzten es einfach weiter, weil <das bisher so> gewesen ist.
MCUA schrieb: >>Quatsch! Stören tun die Waitstates nur wegen ..... > Nein. Waitstates stören fast immer, weils fast immer verlorene Zeit und > vergeudete CPU-Leistung ist. > Die Waitstates sind einfach dazu da, die Architektur übersichtlich und billig zu halten. > >>>>> Und eine X86-CPU interessiert in der EmbeddedWelt so gut wie keinen. >>>>Auch falsch. 386EX lief in riesigen Stückzahlen. Ich selbst mußte mich >>>>mit dem Ding rumärgern. >>> (386EX ist uralt) >>Ja, das ist gewünscht. Man kennt alle Bugs ...... > Bei welchen Leuten schaffst du, dass die froh sind, Bugs hegen und > pflegen zu dürfen ? Da, wo Abstürze und Ausfälle den Umsatz an SMS-Durchleitungen behindern würden. Ich will dich nicht verarschen. Es ist einfach so und kein Einzelfall! Allein schon die Frage, ob es Second-Source gibt, kostet viele mögliche Design-Wins. Und wenn eine Firma 'patented' in das Datenblatt schreibt, ist das genauso ein mögliches Ausschlußkriterium. > >>In meinem konkreten Fall war es die Möglichkeit, einfach DOS aufzusetzen. > Aha. Dos ! geht das vielleicht mit PC ? Die Supporter die die Anlage später im Feld bedienen sollten, kannten DOS. DOS ist zuverlässig, simpel, wenig resourcenhungrig. Das Design ist allerdings 10 Jahre alt. Heute würden die gleichen Entscheidungen zu Linux auf ARM führen. > > >>> Nenn mal <einen> X86-Controller (nicht PC-basierend), der für embeded >>> interessant wäre! >>BECK IPC z.B. > Das ist ein PC !!! Hm. Dann spezifiziere nochmals was du genau meinst. > zu 8051: > Ich kann NICHT EINEN EINZIGEN VORTEUL (mehr) finden, bei dieser CPU. Im > Gegenteil. Die fast überall SCHLECHTER! Also warum drüber reden? > Ich denke, die Leute die '51 heute noch einsetzen, haben einfach keine > Lust sich verschiedene CPUs anzugucken, oder sie stellen nicht (mehr) > die geringste Anforderung an die CPU, und benutzten es einfach weiter, > weil <das bisher so> gewesen ist. Das Datenblatt/-Manual hat einfach keine 1000 Seiten! Der Controller besitzt etliche Second-Sources. Für die Software findet man hunderte von Softwerkern. DAS ALLES ZÄHLT! Klar kann man damit alleine kein IPhone bauen. Es gibt viele Anwendungen wo der Controller nicht allzuviel zu tun hat. Ich vermute, du warst noch nie in einem produktiven Umfeld der Industrie.
MCUA schrieb: >>Quatsch! Stören tun die Waitstates nur wegen ..... > Nein. Waitstates stören fast immer, weils fast immer verlorene Zeit und > vergeudete CPU-Leistung ist. Waitstates stören nur, wenn sie bremsen. Wenn sie durch Massnahmen wie Prefetching und Caching statistisch stark plattgebügelt werden, dann stören sie kaum noch. Wobei ich hier als Definition des Begriffs "Waitstate" die Perspektive des jeweiligen Speichers wähle, nicht die mittlere Sicht des laufenden Programms. Ein Speicher, der bei jedem Zugriff 2 weitere Takte einlegen muss, kann aus Sicht eines laufenden Programms durchaus nahezu frei davon erscheinen. > Cache ist in dem Fall nur für draussen, nicht für drinnen. Ich möchte es ja gerne glauben, aber mir wär's schon lieber, wenn irgendwas im Manual darauf hinweisen würde. Das einzige was ich darin bisher fand spricht dagegen. > Ich kann NICHT EINEN EINZIGEN VORTEUL (mehr) finden, bei dieser CPU. Im > Gegenteil. Die fast überall SCHLECHTER! Also warum drüber reden? Vielleicht, weil es neben einer (teilweise eher subjektiven) Qualität einer Architektur und der von dir postulierten Faulheit der Entwickler noch andere Kriterien gibt? Die meisten Anwender eines 8051-Derivats wollen es nicht vergolden und zum Anbeten auf ein Podest stellen, sondern ganz banal damit Geld verdienen. Wenn dies damit geht, dann ist der Zweck erfüllt. Ich habe auch noch niemanden gefunden, der die x86-Architektur für elegant/gelungen/blablabla hält. Ja, die ist schauderhaft und mittlerweile ein Flickenteppich aus einem Dutzend Erweiterungen mit einer Unmenge an teils nützlichen und teils unnützen Befehlen. Auf AMDs kann man Fliesskommarechnung mit drei vollständig verschiedenen Befehlssätzen durchführen (x87, 3DNow, SSE). Aber die Dinger funktionieren - und darum geht es.
>Ich vermute, du warst noch nie in einem produktiven Umfeld der >Industrie. vielleicht trifft das bei dir zu, denn gerade im -produktiven Umfeld- wird er <nicht mehr> für neue Designs verwendet. Und gut Ent-Softw. kriegt man heute für jeden Controller! 8051 fristet nur noch dort ein Dasein, wo es weder auf Leistung noch auf Effizienz noch auf PeriferieFeatures noch auf gutes PreisLeistVerhältnis ankommt. Nur "Alte Opas" verwenden noch 8051.
Die alten Opas sitzen heutzutage in China und spendieren einem Großteil der Consumergeräte einen oder mehrere 8051. Es gab den Fall einer 68030 mit 40MHz und FPU, die von zwei 6502-Coprozessoren unterstützt wurde. Was sagst du dazu? Du bist einfach etwas überheblich. Denkst zu kurz. Es kommt vor allem auf das gute Preis-Leistungs-Verhältnis an!
>Es kommt vor allem auf das gute Preis-Leistungs-Verhältnis an! Genau. Und das ist gerade bei den Dingern nicht gegeben ! Alle anderen Controller sind entweder billiger oder besser. >sitzen heutzutage in China ... ja und da bauen die das was überall bekannt ist, eben altes 8051-Zeug, und wenn irgentjemand anfängt ne CPU in FPGA zu bauen nimmt er zuerst einen 8051, weil am einfachsten. Ich rede auch nicht von Millionstückzahlen in china (noch dazu von sehr geringer Leistung) sondern von sagen wir mal einigen 1000 hier in Deutschland. ...must mal anere Controler in Detail vergleichen mit '51, dann merkst du es. Das hat mit Überherbl nicht das gerigste zu tun, das ist einfach eine reine techn. Feststellung. Und du kannst mir <keinen> hier kaufbaren 8051 Controler nennen, bei dem es für den gleichen Preis bei anderen Herstellern nicht was bessers gibt, ober bei dem es bei anderen Herstellern die gleichen oder besseren Features nicht zum günstigeren Preis gibt. Und nur darauf kommt es an. Und: Die Projekte, bei denen 8051 noch benutzt wird sind SEIT JAHREN STETIG RÜCKLÄUFIG.
MCUA schrieb: > Und du kannst mir <keinen> hier kaufbaren 8051 Controler nennen, bei dem > es für den gleichen Preis bei anderen Herstellern nicht was bessers > gibt, ober bei dem es bei anderen Herstellern die gleichen oder besseren > Features nicht zum günstigeren Preis gibt. Nenn mir einen der Firma unbekannten Controller, der bei angepeilten 1000 Stück und ein paar Monaten Entwicklungszeit billiger ist als das dem "Opa" bestens bekannte und ausreichende 8051-Derivat. > Und nur darauf kommt es an. Auf den Gesamtpreis kommt es an, nicht allein auf den Stückpreis.
>Nenn mir einen der Firma unbekannten Controller, der bei angepeilten >1000 Stück und ein paar Monaten Entwicklungszeit billiger ist als das >dem "Opa" bestens bekannte und ausreichende 8051-Derivat. >> Und nur darauf kommt es an. ...und deswegen sind die Projekt-zahlen auch stetig fallend und nicht steigend Viele Leute die 8051 einsetzen wissen nichtmal, das sie auch viele Perif. (die auch teuer ist) verzichten könnten, wenn sie was anderes nehmen würden. Und einen anderen Controller (besonders wenn 8 Bit) einzusetzen, dauert auch keine Monate. Im Gegenteil, ich bin mir sicher, das viel gerne einen anderen nehmen würden (insbes. wegen besserer Adr.arten), könnten sie sich nur mal dazu überwinden ein anderes Datenblatt anzusehen.
MCUA schrieb: > Und einen anderen Controller (besonders wenn 8 Bit) einzusetzen, dauert > auch keine Monate. Nehmen wir an, es sei 1 Monat Gesamt(!)verzögerung (ja, bei dir sind es nur 2 Tage, aber nicht jeder ist so schnell) und der Entwickler kostet die Firma mit allem Drum und Dran nur 10000€ in diesem Monat, mitsamt Entwicklungssystem. Macht 10€ umgelegt auf jedes produzierte Gerät. Auf wesentlich längere Sicht mag es sich irgendwann lohnen. Bezogen auf das eine Projekt nicht. Weshalb es sich auch nicht lohnt, jedesmal eine andere Familie zu verwenden, auch wenn der Stückpreis des Controllers 50¢ drunter liegt.
(in 2 Tagen kann ich kein uC wechseln) >Auf wesentlich längere Sicht mag es sich irgendwann lohnen. Genau. und deshalb sollte man, wenn man längerfristig plant, so früh wie möglich von diesem kappesding weggehen übrigens: Intel hat den 8051 auch (wie viele andere Bausteine) links liegen lassen!!! auch das wäre ein Grund, den wegzulegen.
MCUA schrieb: > übrigens: Intel hat den 8051 auch (wie viele andere Bausteine) links > liegen lassen!!! Vermutlich, weil die letzte Fab mit der entsprechenden Technik unrentabel wurde. Intels Produktlinen sind längst auf ganz andere Technik optimiert. Mit dieser Logik solltest du auch DRAMs und Flash-ROMs meiden. Die hatte Intel nämlich auch mal im Programm, aber irgendwann eingestellt.
>Mit dieser Logik solltest du auch DRAMs und Flash-ROMs meiden.
Speucher gibts onmass in gleicher Art von etlichen Herstellern, nicht
CPUs
MCUA schrieb: >>Es kommt vor allem auf das gute Preis-Leistungs-Verhältnis an! > Genau. Und das ist gerade bei den Dingern nicht gegeben ! > Alle anderen Controller sind entweder billiger oder besser. >>sitzen heutzutage in China ... > ja und da bauen die das was überall bekannt ist, eben altes 8051-Zeug, > und wenn irgentjemand anfängt ne CPU in FPGA zu bauen nimmt er zuerst > einen 8051, weil am einfachsten. Nö. Unsere chinesischen Freunde benutzen übrigens auch gerne noch Win98. Gleicher Grund. > > Ich rede auch nicht von Millionstückzahlen in china (noch dazu von sehr > geringer Leistung) sondern von sagen wir mal einigen 1000 hier in > Deutschland. > > ...must mal anere Controler in Detail vergleichen mit '51, dann merkst > du es. > Das hat mit Überherbl nicht das gerigste zu tun, das ist einfach eine > reine techn. Feststellung. Ich habe so viele CPUs beackert, da brauch ich keinen Vergleich scheuen. Höchstens AVR, PIC und dsPIC sagen mir wenig. Das wollte ich mir nicht antun. Irgendwann ist genug. Meinereiner hat sich auf Cypress PSoC für meine kleinen Projekte eingeschossen. > > Und du kannst mir <keinen> hier kaufbaren 8051 Controler nennen, bei dem > es für den gleichen Preis bei anderen Herstellern nicht was bessers > gibt, ober bei dem es bei anderen Herstellern die gleichen oder besseren > Features nicht zum günstigeren Preis gibt. Und nur darauf kommt es an. > Technisch gesehen ist ARM überlegen. Ich bin mit Leib und Seele ein Freund der reinen Lehre, aber im Beruf siehts oft anders aus. > Und: > Die Projekte, bei denen 8051 noch benutzt wird sind SEIT JAHREN STETIG > RÜCKLÄUFIG. Im relativen Verhältnis als Design-Win gebe ich dir gerne Recht. Aber eigentlich nicht direkt aus technischen Gründen, sondern weil heutzutage einfach mehr Auswahl ist. Es gibt schlicht mehr Architekturen und irgendeine wird dann genommen. Oftmals durch relativen Zufall oder sanftes Hinschubsen durch den Application Engineer von Spoerle oder sonstwem. JEDE Firma will eine Abhängigkeit erzeugen. Der Volltreffer ist für diese also eine Design-Entscheidung des Anwenders für ein Produkt, das es so nicht von der Konkurrenz gibt. Totale Abhängigkeit hält den Preis und damit Gewinn oben!
MCUA schrieb: > Viele Leute die 8051 einsetzen wissen nichtmal, das sie auch viele > Perif. (die auch teuer ist) verzichten könnten, wenn sie was anderes > nehmen würden. > > Und einen anderen Controller (besonders wenn 8 Bit) einzusetzen, dauert > auch keine Monate. Im Gegenteil, ich bin mir sicher, das viel gerne > einen anderen nehmen würden (insbes. wegen besserer Adr.arten), könnten > sie sich nur mal dazu überwinden ein anderes Datenblatt anzusehen. Und warum ist dann bei jeder Architektur die Peripherie wie Timer usw. grundsätzlich anders implementiert? Genau, weil jeder Chipentwickler meinte, es besser als die Konkurrenz machen zu können. Und dies dann mit Nachdruck dem Kunden vermittelt wird. Da gibts dann kostenlose Seminare mit einem Kit zum Mitnehmen usw. Aus technischer Sicht wäre nur selten ein Unterschied bei Peripherie sinnvoll. Vielleicht kommt alle 20 Jahre mal was entscheidendes Neues hinzu.
Mal ne Frage: Wieso antwortet keiner mehr? Ich habe doch nicht etwa den Thread kaputtgemacht - sorry.
Abdul K. schrieb: > Mal ne Frage: Wieso antwortet keiner mehr? Ich habe doch nicht etwa den > Thread kaputtgemacht - sorry. Wenn du das hier lesen kannst, dann nicht. Aber mit der ursprünglichen Fragestellung hat der thread eh nichts mehr zu tun - ich schätze mal, ohne Nachzählen, dass sich mit einer Einregistermaschine höchstens 1 % der Antworten beschäftigt haben. Nicht dass ich das bedaure, ich habe ja schon ganz am Anfang geschrieben, dass die Frage keine praktische Relevanz mehr hat. Gruss Reinhard
Es gibt halt interessantere Aspekte und die µC.net Tradition verlangt das Abschweifen sowieso :-)
>Ich habe doch nicht etwa den Thread kaputtgemacht - sorry.
Für mich schon. Wäre nur noch eine Frage: welchen µC bevozugt A.K.,
welche MCUA und welche Du?
Ich bin mir sicher, dass darunter keine 'Accu-Maschine' ist (, für die
man ein Ladegerät braucht).
Tropenhitze schrieb: > Für mich schon. Wäre nur noch eine Frage: welchen µC bevozugt A.K., > welche MCUA und welche Du? Aktuelle Favoriten sind AVR für Kleinkram bis 28 Pins, darüber STM32. Wobei auch PIC24 und PIC18 mit auf der Rechnung sind - die PIC18 weil es nur da 28pinner mit CAN gibt. Ich bin freilich recht flexibel was die Familie angeht. Ich bin kein Profi und ausgesprochen neugierig, was zu ganz anderen Auswahlkriterien als in professionellem Einsatz führt. So kann es vorkommen, dass ich in einer Lösung mit mehreren Controllern schon deshalb verschiedene Familien einsetze, weil's mir bei einer allein zu langweilig wird. > Ich bin mir sicher, dass darunter keine 'Accu-Maschine' ist Stimmt zwar, aber aus anderen Gründen. Gewisse Architekturkriterien spielen zwar eine Rolle. So mag ich den Würgereiz beim Blick auf den erzeugte Code nicht so, der sich bei PIC18 leicht einstellt. Und mir wär's recht, wenn ich auch beim Kleinkram nicht zwischen ROM-Pointern und RAM-Pointern unterscheiden müsste. Am mittelgrossen Programmen (so ab 20-30KB, in AVR-Bytes gemessen) ist diese Adressraumfrage für mich ziemlich dominant, bei kleinen eher nicht. Aber andere Kritierien spielen auch eine wesentliche eine Rolle, wie DIP-Gehäuse (Lötpunktrasteraufbau) und die im Kleinbereich nach wie vor ziemlich praktischen 5V. Weshalb MSP430 zwar meinen Sinn für Ästhetik anspricht, aber nie ernsthaft in Frage kam.
5V muß einfach aussterben, sobald die dahinterstehenden Fabs 'gereinigt' werden. Aktuelle Technik ist nunmal 1,8V oder weniger. Manchmal wird Aufwand getrieben, das es der Anwender nach außen hin nicht sieht. Z.B. gibt es verteilte Spannungsregler in CPLDs. Momentan ist 3,3V als Verbindungstechnik angesagt. DIP interessiert eigentlich nur Bastler und Entwickler. Mich auch z.B. Für den Hersteller ist es schlicht zu aufwändig, eine extra Gehäuseform dafür bereitzuhalten. Große Softwareprojekte schreib ich nicht, bin aber sehr hardwarelastig, daher ist PSoC ne gute Wahl für mich. Nehme auch nix anderes mehr, damit ich nicht den Krampf mit vielen unterschiedlichen Entwicklungsumgebungen ertragen muß. Liebäugeln tue ich noch mit Propeller. Womit wir dann beim nächsten Schritt wären: PC als Terminal für den Forth o. ä. Virtuelle Maschinen finde ich sehr attraktiv. Dort kann man die Architektur praktisch frei nach eigenen Vorstellungen definieren. Z.B. ein serielles EEPROM in den Adressbereich des Prozessors mappen. Was so nirgends geht - oder kennt jemand ein Gegenbeispiel mit einer Losgröße größer Eins?
> 5V muß einfach aussterben, sobald die dahinterstehenden Fabs > 'gereinigt' werden. Aktuelle Technik ist nunmal 1,8V oder weniger. Tja, wenn die Hersteller absichtlich die Kunden ignorieren, kommt so was bei raus. Die Kunden wollen Chips die einerseits mit 0.9V noch laufen, damit man sie direkt an Batterien anschliessen kann, und andere Chips, die 40V aushalten, damit man damit auch mal was steuern kann. Wenn die Hersteller partout an den Kunden vorbeiproduzieren, gewinnen halt andere. National hat begriffen, daß nicht nur OpAmps bis 5.5V einen Markt haben (TI hat das nicht so begriffen) und Microchip hat begriffen, daß, wenn man japanischen/koreanischen/taiwanesischen uC-Herstellern etwas vom Markt wegnehmen will (z.B. Taamagotchis) man mit 3.3V+/-10% CPUs mit vielen mA Stromverbrauch kein Bein an den Boden kriegt (Freescale hat das nicht so begriffen). Nur für grosse Technik lohnen sich Spannungsregler und extra Stromversorgungen.
Jep MaWin. Beispielsweise lief nein läuft immernoch mein geliebter Casio FX-602P mit 2xCR2032, während der in etwa gleichleistungsfähige TI-59 dafür Akkus und ein naheliegendes Netzgerät benötigte. Und der FX war auch seinerzeit vieeel schneller. So alle paar Jahre wechsele ich die Batterien, obwohl er fast jeden Tag mal an ist. Der HP-41CV konnte genausowenig mithalten, hatte aber immerhin schnöde 16-Segmente 'Grafik' während der FX der erste Rechner mit 5x7 Punktmatrix war nö ist. Mal so als Beispiel wie überlegen die Japaner vor 25 Jahren waren.
Abdul K. schrieb: > Virtuelle Maschinen finde ich sehr attraktiv. Dort kann man die > Architektur praktisch frei nach eigenen Vorstellungen definieren. Z.B. > ein serielles EEPROM in den Adressbereich des Prozessors mappen. Wo gibt's das denn? Virtuelle Maschinen sind mir an sich nichts neues, aber bei Controllern unterhalb Linux-Basis bin ich dem noch nicht begegnet.
Für kleine Sachen nehme auch ich AVR. Ansonsten habe ich mir den H8SX1668R als Nachfolger der H8300 angelacht. Auf DIL kann ich/man keine Rücksicht mehr nehmen. Im Gegenteil bin ich froh, nicht auf BGA umsteigen zu müssen. Sehr reizvoll finde ich die neuen Renesas RX mit ihren 100MHz, schönen IOs und FPU. Flash ohne Wartezyklen! Der SH7286 würde mich reizen, weil er noch mit 5V betrieben werden kann und dennoch affenschnell ist. Der Hersteller begründet dies mit höherer Störsicherheit in Motorsteuerungen. Jetzt muß mir nur noch einer einen Auftrag für meine Wunsch-CPUs erteilen. Kleiner Tipp: die Ersten, die sich melden, bekommen Rabatt ;-) Einen fx-450 habe ich auch noch: für dez-bin-oct-hex Umrechnungen.
bernd schrieb: > Noch eine sehr interessante CPU, die ZPU: Yep, aber da sind wir exakt bei den typischen Eigenschaften vieler Stack-Architekturen. Sie sind kompakt aufgebaut und auch recht sparsam im Code. Bei Performance/MHz müssen sie jedoch Federn lassen. Für vergleichbare Leistung benötigt man erheblich mehr Takt oder erheblich mehr Aufwand, denn auf einen normalen RISC-Befehl kommt im Mittel weit mehr als ein ZPU-Befehl. Was dann wohl auch auf mehr Strom rausläuft.
Bei den Stack-Maschinen kommt es auf gute Befehle an, die den rechenintensiven Teil abdecken. Dafür bekommt man unglaubliche Flexibilität wie die Aufhebung zwischen Edit/Compile/Run. So kann man problemlos Code per Terminal injizieren. Für Updates usw. Was ist so toll an der ZPU ? Auf den ersten Blick erscheint sie mir nur als Werbefläche für diese Firma.
Abdul K. schrieb: > Bei den Stack-Maschinen kommt es auf gute Befehle an, die den > rechenintensiven Teil abdecken. Dafür bekommt man unglaubliche > Flexibilität wie die Aufhebung zwischen Edit/Compile/Run. Verwechselst du da grad Stacksprachen wie FORTH mit Stackmaschinen wie ZPU? Den Übergang kann man zwar fliessend gestalten, aber für einen Interpreter braucht man keine Stackmaschine in Hardware.
A. K. schrieb: > Abdul K. schrieb: > >> Virtuelle Maschinen finde ich sehr attraktiv. Dort kann man die >> Architektur praktisch frei nach eigenen Vorstellungen definieren. Z.B. >> ein serielles EEPROM in den Adressbereich des Prozessors mappen. > > Wo gibt's das denn? Virtuelle Maschinen sind mir an sich nichts neues, > aber bei Controllern unterhalb Linux-Basis bin ich dem noch nicht > begegnet. Es gab mal tinyboot.com Da wurde das in externem EEPROM gespeichert. Hatte ich mal mit einem 80C552 Minimodul von Phytec erfolgreich getestet. Ich saß an der Quelle ;-) Dann gabs noch einige andere interessante Sachen. Müßte aber in den Backups gucken. Oh Klasse. sedoparking hatte Tinyboot komplett geblockt. Arschöcher. Hier gibts noch Reste: http://qrpradio.org/pub/Programming/Forth/TinyBoot/ War jedenfalls recht gut gemacht.
> Bei den Stack-Maschinen kommt es auf gute Befehle an, die den > rechenintensiven Teil abdecken. Dafür bekommt man unglaubliche > Flexibilität wie die Aufhebung zwischen Edit/Compile/Run. Du hast mir vorher zwar zugestimmt, ich mus dir hier aber widersprechen: Du verwechselst eine interpretierte Sprache wie Forth mit einer Prozessorarchitektur wie eine Stackmaschine. Deine "Flexibilität" hat jede interpretierte Sprache, auch eine Lisp-Maschine ist "unglaublich Flexibel" was die Ausführung von gerade erfassten Lisp-Funktionen anlangt, oder eine Java-Maschine führt eine objektorientierte prozedurale Sprache auf einer Registermaschine aus. Dafür kann man auf Stack-Computern auch sehr schön z.B. kompilierten C-Code ausführen, dessen Edit/Compile/Run vielleicht ewig dauert, weil Cross-Compiler und Flashen angesagt ist. Die "guten Befehle" einer Stack-Maschine sind eher einfach, die Frage ist, ob die Hardware gewisse Anforderungen der ausgeführten Sprache unterstützt (gibt es ein Display für Funktionen in Funktionen für Pascal, gibt es Harvard oder Neumann-Architektur damit Code auch berechnet werden kann).
Abdul K. schrieb: > http://qrpradio.org/pub/Programming/Forth/TinyBoot/ > War jedenfalls recht gut gemacht. Für sowas sind Maschinen mit getrenntem Adressraum ganz übel, denn für solche Sprachen ist eine Trennung von Code und Daten völlig unnatürlich. Leider trifft das auf die meisten kleinen Controller zu, und für die grossen Klöpse eignet sich das Verfahren eher weniger.
MaWin, du machst immer alles so kompliziert. Am Ende kann man deine Ergüsse für nix mehr gebrauchen. Lisp, Java auf einem PIC womöglich. Du hast noch ADA vergessen! Und wieviele Threads wurden dank dir geblockt? Klar habe ich einige Sätze einfach ausgelassen, damit der Text nicht zu lang wird. Ich verwechsel gar nix, denn das Zeug habe ich alles ausprobiert.
A. K. schrieb: > Abdul K. schrieb: > >> http://qrpradio.org/pub/Programming/Forth/TinyBoot/ >> War jedenfalls recht gut gemacht. > > Für sowas sind Maschinen mit getrenntem Adressraum ganz übel, denn für > solche Sprachen ist eine Trennung von Code und Daten völlig unnatürlich. > Leider trifft das auf die meisten kleinen Controller zu, und für die > grossen Klöpse eignet sich das Verfahren eher weniger. Mir kommt es für meine Projekte nicht auf Geschwindigkeit in der Ausführung an, sondern auf effektive Entwicklung. Genausowenig fahre ich Porsche, sondern Golf. Du verstehst, manche allerdings garantiert nicht.
Abdul K. schrieb: > Mir kommt es für meine Projekte nicht auf Geschwindigkeit in der > Ausführung an, sondern auf effektive Entwicklung. Genausowenig fahre ich > Porsche, sondern Golf. Du verstehst, manche allerdings garantiert nicht. Ich hatte freilich auch nicht gleich kapiert, was du mit dem Begriff der "virtuellen Maschine" gemeint hast. Immerhin ist dieser Begriff heute im Zeitalter von Virtualisierung ziemlich eindeutig festgenagelt. Reste der von dir verwendeten anderen Bedeutung stecken heute noch in Begriffen wie JVM (Java Virtual Machine) drin, aber ich fürchte man sollte heute dafür eine andere Bezeichnung finden, sonst verwirrt es eher. Pseudomaschine vielleicht. Vor etlichen Jahren war ich mal einer Variante begegnet, in der die gewöhnungsbedürftige Forth-Syntax etwas in Richtung Pascal getrimmt war. Lesbarer war. Sah ganz interessant aus. Leider war das dann bald wieder verschwunden. Ohnehin: Ist mal jemand auf die Idee gekommen, den Kram von rechts nach links laufen zu lassen? Dürfte sich leichter lesen lassen (erst recht, wenn man mit APL angefangen hat ;-).
Ich meinte damit die Möglichkeit, Adressen im seriellen EEPROM direkt im Adressraum abzubilden. Schreibe ich z.B. auf 100 Hex gehts ins Prozessor-RAM, 200 Hex geht auf eines der Spezialregister (was übrigens auch nur eine Abbildung ist, aber eben hier üblich), 300 Hex landet auf Adresse 0 Hex im externen EEPROM. usw. Momentan bin ich mir unsicher, ob Tinyboot das überhaupt so realisiert hatte. Obiges Konstrukt lauert aber seit Jahren in meinem Kopf auf Realisierung. Mich stört es jedenfalls an C ganz extrem, das diese Vereinheitlichung nicht durch Pointer erreichbar ist. Jedenfalls habe ich das nie hinbekommen. Ein ähnlich gelagerte Baustelle ist die Adressierung eines Bitarrays an beliebiger Stelle. Und die nächste Erweiterung ist dann, dieses alles auf Netzwerktopologien abzubilden. Ich werde also niemals so alt, um alle Projekte auch nur annähernd umsetzen zu können. Und für die breite Masse eignet sich sowas auch nicht. Da gibts nur C und Win.
Abdul K. schrieb: > Mich stört es jedenfalls an C ganz extrem, das diese Vereinheitlichung > nicht durch Pointer erreichbar ist. Jedenfalls habe ich das nie > hinbekommen. Wird so in manchen Compilern über Pointer-Tagging und Laufzeitfunktionen realisiert. Lässt sich auch über Templates in C++ implementieren.
Irgendwie beruhigend, wenn Profis auch nicht wirklich weiter wissen. Ich finds nur seltsam, das das außer mich niemanden stört. Das stinkt normalerweise nach eigenem Fehler und Nachlernen (für meinereiner). War es nicht so, daß man jedes C++ Programm in ein C-Programm übersetzen kann? Manche Compiler arbeiten so über zwei Schritte hin zu Assembler-Code.
Abdul K. schrieb: > War es nicht so, daß man jedes C++ Programm in ein C-Programm übersetzen > kann? Manche Compiler arbeiten so über zwei Schritte hin zu > Assembler-Code. Der erste C++ Compiler arbeitete so. Ist aber nicht mehr üblich.
Also in C++ gehts, in C nicht. Das widerspricht sich dann aber unter dieser Annahme! Ich kenne nur Keil-C und PSoC-C. In beiden kenne ich dafür kein Konstrukt.
Abdul K. schrieb: > Also in C++ gehts, in C nicht. Das widerspricht sich dann aber unter > dieser Annahme! Widerspricht sich kein bischen. Du kannst in Assembler alles machen, was du in C machen kannst, nur viel umständlicher. Du kannst in C alles machen, was du in C++ machen kannst, nur viel umständlicher - manches halbwegs ehrlich, anderes indem C als high level assembler verwendet wird. Aus dem C++ Code (*pointer) wird dann sinngemäss sowas wie if (pointer->tag == 1) return *(type*)pointer->address; else if (p->tag == 2) return (type)eeprom_read(pointer->address, sizeof(type)); else ... und wenn du Glück hast, dann weiss der Compiler dank inlining, dass tag==1 und optimiert den Kram runter bis auf den load.
Abdul K. schrieb: > Ich kenne nur Keil-C und PSoC-C. In beiden kenne ich dafür kein > Konstrukt. Sowas kennst du nicht? http://www.keil.com/support/man/docs/c51/c51_le_genptrs.htm Was für Speicher Keil damit abdeckt weiss ich nicht. Aber es ist dem Prinzip nach soweit ausbaufähig, dass der Pointerzugriff dir auch die Popel aus der Nase einzeln adressieren und rausziehen könnte, wenn Keil darin einen Sinn sähe.
A. K. schrieb: > Abdul K. schrieb: > >> Ich kenne nur Keil-C und PSoC-C. In beiden kenne ich dafür kein >> Konstrukt. > > Sowas kennst du nicht? > http://www.keil.com/support/man/docs/c51/c51_le_genptrs.htm > > Was für Speicher Keil damit abdeckt weiss ich nicht. Aber es ist dem > Prinzip nach soweit ausbaufähig, dass der Pointerzugriff dir auch die > Popel aus der Nase einzeln adressieren und rausziehen könnte, wenn Keil > darin einen Sinn sähe. Ich hab mit dem Keil seit Jahren nicht mehr gearbeitet, sondern hauptsächlich nur nach Hardware und FPGA-Kram gemacht. Aber jetzt sehe ich, das da irgendwelche Reste in meinem Hirn sind. Ja, kenne ich. Geht leider nicht mit seriellem EEPROM. Keil hat da eine Vorstufe von echten Objekten. Danke für deine intensiven Nachforschungen. So weit wollte ich das gar nicht bereden. Also das es in C nicht aber in C++ geht, bezog sich in deiner Aussage nur auf die direkte Verwendung. Ich meinte vorher die Implementierbarkeit. Klar, selbstgemacht wird irgendwann extrem unübersichtlich. Mit einem höher entwickelten Sprachkonstrukt wird der Quelltext dann einfach wieder kürzer...
>Was ist so toll an der ZPU ? Auf den ersten Blick erscheint sie mir nur >als Werbefläche für diese Firma. Das tolle an der ZPU ist, dass sie mit extrem wenig Hardareaufwand gemacht ist, dass es den GCC dafür gibt und das man die ZPU in ein eigenes FPGA implementieren kann. Außerdem ist es relativ einfach, einen eigenen Simulator dafür zu programmieren. Zusätzlich ist es bei so einer Stack bassierten CPU ziemlich einfach eine "Multi-Thread" CPU daraus zu machen, so dass man sich Interrupts sparen kann und für jeden Task einen eigenen Thread macht.
Bernd, hast du das Teil zum Laufen gebracht? Was wäre das kleinste FPGA dafür? Und könnte man z.B. solche seriell-EEPROM dort in den Adressbereich mappen?
Interessante Diskussion hier. Bez. generic pointer: Macht beim 8051 nicht nur der Keil so, sondern auch der SDCC. Vom Prinzip ist ein "generic pointer" ein Pointer, der auf 24-Bit aufgebohrt wurde um Informationen über den Speicherbereich(8bit, -> code, iram oder xram) und die Längste vorkommende Adresse (16-Bit im xram) aufnehmen zu können. Machts nicht grade schneller auf dem armen 8-bitter, der das, bei jedem Zugriff, in Software außwerten muss.
anonymous schrieb: > Vom Prinzip ist ein "generic pointer" ein Pointer, der auf 24-Bit > aufgebohrt wurde um Informationen über den Speicherbereich(8bit, -> > code, iram oder xram) und die Längste vorkommende Adresse (16-Bit im > xram) aufnehmen zu können. Machts nicht grade schneller auf dem armen > 8-bitter, der das, bei jedem Zugriff, in Software außwerten muss. Harvards Rache. Von Neumann lacht. Gruss Reinhard
Reinhard Kern schrieb: > anonymous schrieb: >> Vom Prinzip ist ein "generic pointer" ein Pointer, der auf 24-Bit >> aufgebohrt wurde um Informationen über den Speicherbereich(8bit, -> >> code, iram oder xram) und die Längste vorkommende Adresse (16-Bit im >> xram) aufnehmen zu können. Machts nicht grade schneller auf dem armen >> 8-bitter, der das, bei jedem Zugriff, in Software außwerten muss. > > Harvards Rache. Von Neumann lacht. Na Reinhard, da hast aber echt kurz gedacht. Stell dir vor, du gibst dem ersten Byte weitere Wertebereiche wie eben das angesprochene externe serielle EEPROM. Oder noch viel interessanter, das Byte wird die Netzwerkadresse in deinem RS485-Netz! Da wirds dann spannend!
@ Abdul K. (ehydra) Benutzerseite >serielle EEPROM. Oder noch viel interessanter, das Byte wird die >Netzwerkadresse in deinem RS485-Netz! Da wirds dann spannend! Dann wirds endgültig Unsinn. Da kannst du ja gleich Java nehmen. MfG Falk
Abdul K. schrieb: > serielle EEPROM. Oder noch viel interessanter, das Byte wird die > Netzwerkadresse in deinem RS485-Netz! Da wirds dann spannend! Vor allem auf einem einfachen Mikrocontroller, auf dan man bei späteren Querlesen vom Code nicht damit rechnet, dass ein scheinbar simpler Speicherzugriff in C nach zig Millisekunden mit Timeout rausfliegt, weil das Ziel der Adressierung grad Urlaub macht. Nö, alle Abstraktion in Ehren, aber da sehe ich nicht viel Sinn drin. Bei grösseren Kisten hat man virtuellen Speicher und entsprechende Traps. Da passt das ggf. rein. Aber ein Mega8 mit virtuellem Speicher? Ein Hausnetz aus zig 8-Bit Controllern mit einem single address space model ist schon etwas bizarr (und höllisch fehlerträchtig, "spannend" trifft es daher recht gut ;-).
Wenn man immer nur im alten Schema denkt, dreht man sich immer im Kreis, nicht in einer Spirale wenigstens! Aus Java kommt hier bei mir höchstens der Kaffee. Gibt aber ne FPGA-CPU für Java.
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.