mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Einregister- vs. Mehrregistermaschine


Autor: Иван S. (ivan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Grrrr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Иван S. schrieb:
> Freue mich auch Meinungen,

Worüber denn? Ist 'ne typische Seminaraufgabe.

Autor: Grrrr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur die Frage fehlt halt.

Autor: der mechatroniker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Als Universalmaschine die erste (Bauchgefühl).

In der Signalverarbeitung, wenn ich weiß, dass ich einen 
31-Tap-FIR-Filter implementieren muss: die zweite ;-)

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Иван 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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Иван 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.

Autor: R. Freitag (rfr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Иван S. (ivan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hans Mayer (hansilein)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Иван 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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.).

Autor: Иван S. (ivan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin für ein Verschieben des Threads in de.alt.verhaltenspsychiologie 
. . .

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Иван 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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Иван 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.

Autor: Иван S. (ivan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Иван S. (ivan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Иван 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).

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Иван 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.

Autor: Michael G. (let)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Иван S. schrieb:
> Allein schon wegen "gleichzeitige Ausführung
> unabhängiger Befehle".

http://de.wikipedia.org/wiki/Superskalar

Autor: Иван S. (ivan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Иван 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.

Autor: Michael G. (let)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Иван 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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael G. (let)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Иван S. (ivan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael G. (let)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Bernhard R. (barnyhh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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.

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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!

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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 ?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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...).

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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!.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tropenhitze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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 :-)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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!)

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ach... Praktisch die gesamte IT-Welt jenseits der 8/16-Bit Controller

Du wolltest sagen: jenseits der bitseriellen 1 bit Controller.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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-faste...

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_a...

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Bingo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Welche sind das?
u. a. z. B.:
http://www.renesas.eu/_print_this_page_/products/m...
oder
http://www.renesas.com/products/mpumcu/superh/sh72...


>Und warum machen das nur die?
Weil das auch ein bißchen teurer ist und ein Geizhals das nicht 
versteht.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
RX(CISC)- u. SH(RISC)- Controller gehen bis 100MHz, auch das Flash.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tropenhitze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tropenhitze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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 :-)

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Tropenhitze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Solche Sicherheit, basierend einzig auf den zwei Worten "single cycle"
>ist mutig.

Dem Mutigen gehört die Welt!

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tropenhitze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://elmicro.com/files/renesas/monos_flash_ewc_2...

Bevor wir wieder zu laut werden :-)

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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".

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tropenhitze schrieb:
> http://elmicro.com/files/renesas/monos_flash_ewc_2...
>
> 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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> http://elmicro.com/files/renesas/monos_flash_ewc_2...

Und das alles wegen CO2-Einsparung ?? (letzter Satz).

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man muß das nur oft genug wiederholen, dann glaubts jeder. 
Arbeitslosigkeit und Hunger ist nicht schlimm, produziert auch weniger 
CO2.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
(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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Mit dieser Logik solltest du auch DRAMs und Flash-ROMs meiden.
Speucher gibts onmass in gleicher Art von etlichen Herstellern, nicht 
CPUs

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal ne Frage: Wieso antwortet keiner mehr? Ich habe doch nicht etwa den 
Thread kaputtgemacht - sorry.

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt halt interessantere Aspekte und die µC.net Tradition verlangt 
das Abschweifen sowieso :-)

Autor: Tropenhitze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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).

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch eine sehr interessante CPU, die ZPU:

http://www.opencores.org/project,zpu

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>  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.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tropenhitze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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).

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-).

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: anonymous (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-).

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.