mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ARM7 - Cycles per Instruction?


Autor: Flo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi zusammen,

ich muss momentan für meine Abschlussarbeit einige Messungen an unserer 
Software vornehmen. Wir arbeiten auf dem Atmel AT91SAM7X256. Habe mir 
auch schon ein Verfahren überlegt, dazu muss ich allerdings wissen, 
wieviele Cycles die verschiedenen Instructions benötigen.
Beim AVR ist das immer im Datenblatt bei der ensprechenden Instruction 
mit angegeben. Für den ARM7 finde ich aber leider nichts entsprechendes.

Habt ihr eine Idee, wo ich solche angaben finde, wie zB. "ADD needs 2 
cycles for computation"?

Danke!
Gruß
Flo

Autor: opa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau mal auf arm.com. Da gibts irgendwo ne pdf mit dem Befehlssatz 
(arm7tdmi).

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Flo schrieb:

> Beim AVR ist das immer im Datenblatt bei der ensprechenden Instruction
> mit angegeben. Für den ARM7 finde ich aber leider nichts entsprechendes.

Sowas findet man in der Dokumentation des betreffenden ARM-Cores, bei 
ARM7 ist das meist ARM7TDMI oder ARM7TDMI-S, zu finden bei ARM.

Dazu addieren sich allerdings nicht selten der eine oder andere 
Waitstate, beispielsweise aufgrund Flash- oder I/O-Zugriff. Und damit 
wird es etwas komplizierter, denn nun muss man die Chip-neutrale 
Information in der ARM7TDMI-Dokumentation mit der Flash-Dokumentation 
des betreffenden realen Chips kombinieren.

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Messen.
Über einen Timer den Sysclock zählen, dann weiß Du das ganz genau. Ohne 
mühsames Studium der Doku.

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist beim ARM7 nicht ganz so einfach wie bei einem AVR. Oft sind die 
Ausfuehrungszeiten davon abhaengig welche Operanden im Spiel sind, ob 
der Befehl sequentiell angesprochen wird oder nach eine Verzweigung, 
welche Busbreiten zum Programm vorhanden sind, wie schnell die Speicher 
sind... soll ich noch weiter machen?

Es gibt allerdings eine Angabe in der "allgemeinen Literatur", die sich 
mit ARM cores beschaeftigt. Kannst Dir Deinen Lieblingswert raussuchen. 
Wonach googeln?  "CPI of ARM7"  Der von ARM genannte Durchschnittswert 
liegt bei 1,9 CPI fuer den ARM7 und bei 1,5 CPI fuer den ARM9.

Referenz: 
http://infocenter.arm.com/help/index.jsp?topic=/co...

Das sollte schon mal weiterhelfen.

Viel Spass, Robert

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Flo schrieb:

> ich muss momentan für meine Abschlussarbeit einige Messungen an unserer
> Software vornehmen. Wir arbeiten auf dem Atmel AT91SAM7X256.

Einfachste Möglichkeit, wenn noch irgendwo ein Pin frei ist: Pin beim 
Eintritt in den betreffenden Programmteil setzen, beim Austritt löschen, 
und die Zeit am Oszi oder Logicanalyzer ausmessen.

Zweitbeste Lösung, für Rechenroutinen: Simulator bemühen.

fchk

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wer auch immer diese Fragestellung erfunden hat, ist ein echter ARM 
Experte NOT!
Angenommen der SAM7X laeuft bei 20 MHz vom Flash ohne WS, dann kommt man 
mit den Messungen die o.g. sind einigermassen hin und man ist in der 
Naehe der Werte was "EIN ARM7" kann. Laeuft derselbe uC mit 55 MHz, wird 
dieser Wert schon deutlich schlechter, nimmt man aber einen Analog 
devices ARM7 dann laeuft der noch viel langsamer oder einen STR7 bei 55 
MHz zum abgewoehnen. Ist es aber ein LPC2000, dann laeuft der ploetzlich 
bei 55 MHz (oder auch mehr) mit den besten CPI.
Naechte Huerde, ist es ARM Mode oder Thumb Mode? Bei ARM Mode wird der 
Geschwindigkeitsunterschied zwischen den Chips drastisch, bei Thumbmode 
ruecken sie naeher zusammen weil die uCs mit der besten Bus-Bandbreite 
durch den Thumb-Mode gedrosselt werden.
Je nach Anwendungsfall, ARM Mode oder Thumb Mode, spezifischer 
Bus-Implementierung, spezifischer Taktrate werden z.T. EXTREM 
unterschiedliche Werte, locker mal ein Unterschied von Faktor > 2 beim 
"ARM7".

Also die Fragestellung, die ein reproduzierbares Ergebnis bringen soll, 
muss den Chip (check), die Taktfrequenz?, das spezifische Programm?, 
ARM/Thumb?..... vorschreiben. Dann kann gemessen werden und die Anzahl 
der ausgefuerten Befehle durch die gemessene Zeit geteilt werden wie 
oben vorgeschlagen.

Dei Frage ist so aehnlich wie "Wie lange dauert es von Deutschland nach 
Frankreich mit dem Bus" :-)

Genug gelaestert!

Gruss, Robert

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Dei Frage ist so aehnlich wie "Wie lange dauert es von Deutschland nach
>Frankreich mit dem Bus" :-)
Ist es nicht.
Er hat nach einem ganz konkreten Prozessor gefragt, nicht allgemein nach 
ARM7.
Ausserdem muss jeder Chip-CPU-Hersteller gefälligst genau definierte und 
reproduzierbare Cy-Werte für JEDEN  ASM-Befehl angeben. (alles andere 
wäre Verschleierung von Leistungs-Daten)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MCUA schrieb:

> Ausserdem muss jeder Chip-CPU-Hersteller gefälligst genau definierte und
> reproduzierbare Cy-Werte für JEDEN  ASM-Befehl angeben. (alles andere
> wäre Verschleierung von Leistungs-Daten)

Ist auch der Fall, jedenfalls solange wir uns in der ARM7-Region und 
einem durch nichts gebremsten Core bewegen. Nur reichen die 
entsprechenden Zahlen für den ARM-Core für sich allein betrachtet in der 
Realität nicht aus, denn begrenzte Zugriffszeit und Bandbreite vom 
Flash-ROM ist nicht ARMs Problem, sondern Atmels.

Folglich muss man als Anwender, der sowas wissen will, die Zahlen von 
ARM mit Nebeneffekten der Atmel'schen Integration in den Controller 
kombinieren. Zwar kann man bei Atmel den Einfluss von Flash-bedingten 
Waitstates in den einzelnen Befehl noch einrechnen (wenn man 
Core-Architektur und Flash-Architektur verstanden hat), aber auch dann 
ist man noch nicht am Ende. Weil je nach ARM/Thumb-Modus, 
Flash-Bandbreite und exakter Befehlsfolge noch Einflüsse des 
sequentiellen Instruction-Fetch einfliessen können (*). Spätestens hier 
ist mit der einfachen Rechnung nach dem Muster "Der Befehl soundso 
braucht N Takte" Schluss. Das Caching von Flash-Zugriffen schon bei den 
alten LPC2000ern macht solchen Rechnungen endgültig den Garaus.

Mit zunehmender Komplexität der implementierten Architektur geht der 
Zusammenhang zwischen der nominellen Performance eines einzelnen Befehls 
und der real messbaren Performance immer weiter verloren. 
AVRs,PICs,8051er befinden sich am einen Ende dieser Skala, 
PC-Prozessoren am anderen.

Wer damit nicht leben kann, der sollte sich auf die Klasse der AVRs 
beschränken.

*: Atmel SAM7 hat bei voller Taktfrequenz zu wenig Flash-Bandbreite, um 
die nativen ARM-Befehle ungebremst auszuführen. Weil pro Befehl 2 Takte 
für's Flash draufgehen, viele Befehle jedoch nur 1 Takt benötigen. Im 
Thumb-Modus passt es jedoch.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Mit zunehmender Komplexität der implementierten Architektur geht der
>Zusammenhang zwischen der nominellen Performance eines einzelnen Befehls
>und der real messbaren Performance immer weiter verloren.
Es ist aber DENNOCH möglich, für jeden denkbaren Fall (zB im Cash 
ja/nein, in der Flash-"Pipeline" ja/nein , Einfluss des vorigen 
Befehls.. usw) die Cy-Anzahl anzugeben. Das sind nicht oo viele Werte.
Auch ist zB SH2-A rel. leistungsfähig (mehr als zB ARM7), aber es ist 
keinerlei Problem die Cy-Anzahl raus zufinden!
Aber es ist wohl so, dass gerade Hersteller, die betr Cy-Zahl eher 
schlecht dastehen dies auch etwas verbergen oder verschleiern wollen. 
Das trifft wohl umsomehr auf Hersteller zu, die keinen eigenen Kern 
haben, die verweissen dann auf alles mögliche, nur nicht auf konkr. 
Werte.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MCUA schrieb:

> Es ist aber DENNOCH möglich, für jeden denkbaren Fall (zB im Cash
> ja/nein, in der Flash-"Pipeline" ja/nein , Einfluss des vorigen
> Befehls.. usw) die Cy-Anzahl anzugeben. Das sind nicht oo viele Werte.

Wenn das immer möglich ist, dann mach mir bitte das Vergüngen, eine 
solche Tabelle für den Pentium 4 aufzustellen. Eine, bei der die Summe 
der daraus entnommenen Befehlslaufzeiten exakt die Performance von 
Programmen ergibt. Es wäre auch von Vorteil, wenn sie in Papierform noch 
auf einen LKW passt.

> Auch ist zB SH2-A rel. leistungsfähig (mehr als zB ARM7), aber es ist
> keinerlei Problem die Cy-Anzahl raus zufinden!

In dieser Frage zählt nicht die absolute Performance, sondern die 
Komplexität der Archtektur. Ausserdem hatten wir meiner Erinnerung nach 
schon früher festgestellt, dass wir bei den damals erwähnten SHs in 
dieser Hinsicht unterschiedlicher Ansicht sind.

Autor: Maxx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das sind mehr als nur ein "paar Zahlen".
Da spielen dann Busstrukturen noch mit rein, bzw ob und wie lang ein 
Peripheriedevice (USB, Ethernet, etc) im Busmaster den blockiert. Oder 
gar die Waistates per Register konfigurierbar sind.

Die Zeiten der Instruktionen kannst du dennoch genau berechnen du musst 
nur auf eine menge Dinge achten, wenn du die x+N+S Angaben mit 
tatsächlich vorhandene Konfiguration verrechnest.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wenn das immer möglich ist, dann mach mir bitte das Vergüngen, eine
>solche Tabelle für den Pentium 4 aufzustellen.
X86 steht bei den meinsten Proj. eh nicht zur Diskussion, auch keine 
extrem lange Pipeline, auch keine GHz. (aber das hatten wir ja schon)

>Da spielen dann Busstrukturen noch mit rein...
Ach, und das kann man nicht mit angeben ???

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MCUA schrieb:

> X86 steht bei den meinsten Proj. eh nicht zur Diskussion, auch keine
> extrem lange Pipeline, auch keine GHz. (aber das hatten wir ja schon)

Dann fangen wir und beim schon recht alten LPC2106 an, einen typischen 
Controller. Zwar kann man da problemlos angeben, wie lang ein Ladebefehl 
dauert, abhängig davon
- ob der Befehl aus dem RAM, dem Flash oder einem Flash-Puffer kommt,
- ob die Daten aus dem RAM, dem Flash oder einem Flash-Puffer kommen.

Man kann das alles also noch sauber aufstellen, als Formel mit ein paar 
Abhängigkeiten. Aber hat nicht viel davon, weil zwar meisten weiss, ob 
der Kram aus dem Flash kommt oder nicht, aber man recht oft nicht genau 
weiss, ob diese Befehle und Daten aus dem Flash oder dem Flash-Puffer 
kommen.

Die x86-er hatte ich erwähnt, um deine Aussage "Es ist aber DENNOCH 
möglich, für jeden denkbaren Fall ..." ins absurde zu ziehen. Denn mit 
steigender Komplexität ist das eben immer weniger möglich und vor allem 
immer weniger sinnvoll. Die x86er sind hier nur der offensichtliche 
Extremfall, das fängt aber schon viel früher im Kleinen an.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MCUA schrieb:

>>Da spielen dann Busstrukturen noch mit rein...
> Ach, und das kann man nicht mit angeben ???

Wird schwierig, weil auch dort Pufferung auftreten kann, es damit vom 
Kontext abhängt. Zudem kann der Bus niedriger getaktet sein, was 
unbekannte Synchronisationverluste mit dem Bustakt einbringt.

Was du verlangst ist nichts weniger als ein separater Wälzer, der alle 
Details der Implementierung exakt beschreibt, mit exakten Taktangaben 
und Formeln, wie man das zusammenrechnet.

Nur wird diesen Schinken abgesehen von einigen Extremfällen taktgenauer 
Reproduktion kaum einer lesen. Für taktgenaues Arbeiten sind diese 
Controller sowieso ungeeignet, da sollte man sich jenseits der 
AVR-Klasse auf FPGAs oder XMOS/Propeller verlegen.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>- ob der Befehl aus dem RAM, dem Flash oder einem Flash-Puffer kommt,
>- ob die Daten aus dem RAM, dem Flash oder einem Flash-Puffer kommen.
sind gerade mal 9 Varianten. Dafür braucht man keinen LKW.

>aber man recht oft nicht genau weiss...
wenn es zeitkritisch sein soll, muss man es wissen

>Da spielen dann Busstrukturen noch mit rein, bzw ob und wie lang ein
>Peripheriedevice (USB, Ethernet, etc) im Busmaster den blockiert.
Dann gibt man (muss man) einfach die Cy für unbelegten Bus angeben (und 
wie lange der Befehl max den Bus belegen kann). dadurch ergibt sich auch 
der Wert für den nächsten Befehl.
Und grössere Übertragungen müssen sowiso anders gemacht werden, zB über 
DMA, cpu-cycle-steal o.ä.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MCUA schrieb:

> sind gerade mal 9 Varianten. Dafür braucht man keinen LKW.

Diese 9 Varianten betreffen einen Aspekt. Der Peripheriebus kommt 
hinzu. Das ist die Krux daran: Diese Variabilität der Laufzeit wächst 
exponentiell mit der Komplexität.

Der LKW bezog sich auf den Pentium 4. Und sollte andeuten, dass 
exponentielles Wachstum sehr schnell etwas unhandlich wird.

Autor: Flo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die vielen Antworten!
...da hab ich ja was losgetreten ;-)
Dass die Architektur so komplex ist, dass die Ausführungszeit 
verschiedener Befehler nicht mehr so genau bestimmt werden kann 
(zumindest ohne großen Aufwand), war mir nicht klar.
Das was ich eigentlich erreichen will, ist eine (eher grobe) Abschätzung 
der verbleibenden Rechenkapazität - sagen wir im pessimistischen 
Average-Case - damit ich weiß, wieviel ich noch nebenbei rechnen kann.
Die genauen Zyklen zu zählen macht schon deshalb keinen Sinn, weil die 
Ausführungszeit auch von externen Einflüssen abhängt (Kommunikation 
etc.).

Ich wollte daher einfach zunächst im kompletten Rest der Rechenzeit 
einen Zähler laufen lassen, den ich nach einigen Minuten auslese und das 
Ergebnis mit der Anzahl der Zyklen, die für das Inkrementieren und die 
Schleife benötigt werden, multiplizieren. Wie gesagt, es geht um 
Durchschnittswerte.
Wenn ich das richtig sehe, dauern Data Operations ohne Shiften immer 
genau 1 Cycle. Unklar sind also noch die Geschwindigkeit, mit der die 
Instructions aus dem Flash gelesen werden, sowie die Zeit, die für das 
Speichern des Wertes in den RAM benötigt wird, richtig?

Ich zähle für meine Schleife 12 cycles, und komme bei einer 
100-Sekunden-Messung regelmäßig auf ca. 3,5 Mrd. Cycles (ohne das unsere 
Software nebenher läuft). Kann ich dann bei einer Taktung von 48 MHz 
davon ausgehen, dass in diesem Programm etwa 1,3 Mrd. Cycle-Times für 
den Speicherzugriff draufgehen, oder ist das zu naiv?
Sprich: 48 cy/s - (3 500 000 000 cy / 100s) = 1,3 Mrd. cy/s

Gruß
Flo

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Flo schrieb:

> Wenn ich das richtig sehe, dauern Data Operations ohne Shiften immer
> genau 1 Cycle. Unklar sind also noch die Geschwindigkeit, mit der die
> Instructions aus dem Flash gelesen werden,

Korrekt. Das Flash ist 32 Bits breit und benötigt bei 48MHz 2 Takte pro 
Wort. Infolgedessen ist beim SAM7 mit Code im Flash der Thumb-Modus 
schneller als der ARM-Modus.

Zeitkritischen Code kann man als ARM-Code ins interne RAM legen, dann 
gelten die Regeln der ARM7TDMI-Doku von ARM (ausser bei IO-Zugriffen), 
da keine Wartezyklen auftreten.

> sowie die Zeit, die für das
> Speichern des Wertes in den RAM benötigt wird, richtig?

Lesen/Schreiben in internes RAM ist stets 1 Takt.

Den letzten Absatz habe ich nicht verstanden.

Autor: Flo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey, danke dir!
Habe gerade nochmal eine Messung gemacht und es passt perfekt, wenn ich 
2 Zyklen pro Instruction draufschlage.
Steht das im Datenblatt des AT91SAM7X256, oder woher hast du die Infos? 
Hatte diese Angabe nämlich trotz Suche noch nicht gefunden.

Gruß
Flo

Autor: 123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok jetst erklären sich auch meine niedrigen messergebnisse bei meinem 
SAM7

FLASh 1Cicel bis 30 MHZ. danach sind waitstates notwendig. ( nur noch 
halbe leistung, da auf das flash gewartet werden muss )

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Flo schrieb:

> Steht das im Datenblatt des AT91SAM7X256, oder woher hast du die Infos?
> Hatte diese Angabe nämlich trotz Suche noch nicht gefunden.

Steht drin, aber leicht verschlüsselt zum mitdenken.

Dass das Flash 32 Bits breit operiert und bei vollem Takt einen 
Waitstate benötigt steht drin. Dass dieser Zugriff nicht gepipelined ist 
geht aus dem Timing in "Flash Read Operations" hervor. Dass native ARM 
Befehle 32 Bits breit sind darf als bekannt vorausgesetzt werden. Um das 
zu verknüpfen sind die grauen Zellen zuständig.

Das heisst allerdings nicht, dass auf jeden Befehl 2 Takte oben drauf 
kommen. Sondern dass für jedes 32bit Befehlswort ein zusätzlicher 
Flashzugriffstakt addiert werden muss.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Der Peripheriebus kommt hinzu.
Der kommt nicht hinzu, sondern wird in der Cy's-Tab. einfach mit 
angegeben.

Ausserdem bei DSPs ist es uU noch komplexer, weil mehrere (Code- Data- 
Perif-) Busse drin und auch Par-Befehle drin, und selbst da lässt sich 
die Cy-Zahl eindeutig bestimmen.

Es ist auch falsch, pauschal von 1 Cy auszugeben, wenn die Werte schon 
in der CPU sind.

(Man kann sich diese Flash-Werte-heranhol-Quatsch-Rechnung sparen, wenn 
man bessere Prozessoren nimmt.)

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MCUA schrieb:
>>- ob der Befehl aus dem RAM, dem Flash oder einem Flash-Puffer kommt,
>>- ob die Daten aus dem RAM, dem Flash oder einem Flash-Puffer kommen.
> sind gerade mal 9 Varianten. Dafür braucht man keinen LKW.
>
>>aber man recht oft nicht genau weiss...
> wenn es zeitkritisch sein soll, muss man es wissen

Nicht wirklich. Es gibt nur extrem wenige Anwendungen in denen Code 
nicht schneller als ein vorgegebener Wert sein darf. Es gibt so manche 
wo der Code nicht langsamer als ein vorgegebener Wert sein darf. Also 
andersrum, es gibt eine Anzahl von Anwendungen die vorschreiben, dass 
ein Teil des Codes (z.B. eine Interrupt Routine)nicht laenger als x usec 
dauern darf aber nur wenige die sagen, das System bricht zusammen wenn 
der Interrutp weniger als x usec braucht. Dazu braucht man in der Regel 
keine Zuklen zaehlen, wenn doch, sollte man ueber einen schnelleren 
Prozessor / Microcontroller nachdenken.
>
>>Da spielen dann Busstrukturen noch mit rein, bzw ob und wie lang ein
>>Peripheriedevice (USB, Ethernet, etc) im Busmaster den blockiert.
> Dann gibt man (muss man) einfach die Cy für unbelegten Bus angeben (und
> wie lange der Befehl max den Bus belegen kann). dadurch ergibt sich auch
> der Wert für den nächsten Befehl.
> Und grössere Übertragungen müssen sowiso anders gemacht werden, zB über
> DMA, cpu-cycle-steal o.ä.

Mein urspruenglicher MCU Hintergrund ist auch ein Micro der ein 
einfaches Muster fuer die Anzahl der Zyklen bietet und ich hab in meinen 
ersten 2 ARM Jahren auch oft danach geforscht um herauszufinden, dass es 
den allermeisten Kunden extrem Wurscht ist wieviel Zyklen es dauert. 
Viele wollen aber wissen ob Ihre Aufgaben in einer vorgegebenen Zeit 
bearbeitet werden koennen.

Nochmal mein Bus nach Frankreich :) der dieses mal von Freiburg nach 
Strassburg faehrt. Es reicht den allermeisten Reisenden als Auskunft, 
dass es normalerweisse weniger als 2h dauert, dass sie 8h in Strassburg 
bummeln koennen und dann wieder 2h zurueckfahren. Es wird allerdings 
auch solche geben, die wissen wollen ob es "typischerweisse" 97 oder 101 
Minuten dauert oder vielleicht die Zyklengenauen wollen wissen wieviele 
Radumdrehungen bei einem neuen Reifen notwendig sind.

Es ist moeglich eine kurze Befehlssequenz, die nicht unterbrochen wird 
fuer einen bestimmten Baustein zyklengenau zu berechnen, wuerde ich 
allerdings nicht tun. Ich wuerde den Simulator von Keil hernehmen und 
dann bin ich im Bereich <10% Ungenauigkeit, mindestens ist das meine 
Erfahrung mit den LPCs. Andererseits ist es auch meine Erfahrung, dass 
Kunden, die versucht haben zyklengenau zu berechnen bereits bei 
Sequenzen von 10-20 ASM Befehlen mehr als 10% daneben lagen.

Uebrigens, der Titel ARM7 - Cycles per Intruction war der Hintergrund 
meine Analogien. Der besser spezifizierte Inhalt, dass es sich um einen 
SAM7X handelt macht es einfacher aber ohne die Werte Frequenz und 
ARM/Thumbmode immer noch unmoeglich die CPI zu bestimmen bzw. es gibt 
mehrere Werte. Alle diese Werte sind nicht representativ fuer "den 
ARM7", Bezug wiederum Titel des Threads.

Nun einige Punkte, um etwas mehr Verwirrung zu stiften.
Der SAM7X hat bei 30 MHz sowohl im ARM mode als auch im Thumb mode einen 
besseren Wert fuer CPI ald der LPC2xxx, ist aber trotzdem eine Ecke von 
seiner maximalen Performance (55 MHz Thumb Mode) weg.
Der LPC2xxx hat bei > 30 MHz einen viel besseren CPI im ARM mode als der 
SAM7X.
Die Performance des SAM7X bei 30 MHz im ARM Mode ist besser als die 
Performance bei 36 MHz im Thumb mode ABER die Performance bei 36 MHz im 
ARM Mode ist schlechter als die bei 36 MHz im Thumb Mode.
Der LPC2xxx bei 55 MHz im ARM mode hat vielleicht immer noch keine 
bessere CPI als der SAM7X im Thumb Mode, ist aber trotzdem zwischen 
20-30% schneller weil dort der ARM Mode ohne die Bus-Bremse laeuft.

Jetzt meine Frage and den Experten MCUA, kannst Du das alles erklaeren?
p.s. ich koennte, aber dafuer muesste mich schon einer bezahlen, denn es 
dauert zu lange :-)

Robert

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Es gibt nur extrem wenige Anwendungen in denen Code
>nicht schneller als ein vorgegebener Wert sein darf.
Sorry. Unsinn.
Code ist evtl zu langsam, nicht zu schnell. (er wird höchstens evtl 
später benötigt, kann aber nicht zu schnell sein)

>Es gibt so manche wo der Code nicht langsamer als ein vorgegebener Wert >sein 
darf.
Also muss es evtl optimiert werden, und dann sind wer doch wieder bei 
den Cy's.
Und bsp. bei kurzen INT-Rout (mit rel wenig Bef.) interess die Cy's 
besonders, da dort viel "Geschwindig" heraus geholt werden kann.

>Nochmal mein Bus nach Frankreich
achso.

>Jetzt meine Frage and den Experten MCUA, kannst Du das alles erklaeren?
Muss alles in DS stehen.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MCUA schrieb:

>>Jetzt meine Frage and den Experten MCUA, kannst Du das alles erklaeren?

> Muss alles in DS stehen.

Tut es auch. Seine Frage war wohl, ob du es dort findest. Ich schon. 
Freilich kann man von Atmel kaum erwarten, dass sie ins Datasheet den 
Vergleich mit LPC2000 direkt reinschreiben. Bischen suchen muss da schon 
sein dürfen.

Generell gibt es in dieser Klasse eher wenig Implementierungen, die 
taktgenau papiergetreues Timing erlauben, mag dein heissgeliebter SH2 
nun zu denen gehören oder nicht. Wenn man derart knapp dran ist und sich 
rein auf Papier verlässt ohne mindestens die genannten 10% Toleranz des 
Keil'schen Simulators einzuplanen, dann hat man m.E. vorneweg was falsch 
gemacht.

Wenn das für dich alle solchen "fuzzy" Architekturen disqualifiziert, 
dann sei es so. So hat eben jeder seine eigenen Kriterien. Für 
taktgetreues Verhalten such ich woanders.

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@MCUA
OK, ich geb auf, gegen solches geballtes Wissen und allumfassende 
Weisheit kann ich nicht an.

@A.K.
Danke fuer den Versuch in anderen Worten die Sachlage zu klaeren.

Bleibt zu hoffen, dass diejenigen, die eine zyklen genaue Ausfuehrung 
benoetigen nichts uebersehen und ihren Job behalten.

Gruss, Robert

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wenn man derart knapp dran ist
so plant norm.weise keiner (ich auch nicht)
>dein heissgeliebter SH2
falsch

"fuzzy" Architekturen und "fuzzy" Datenblätter sind 2 paar schuhe

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nuja... Robert hat m.W. solche Datasheets geschrieben. Ich könnte mir 
vorstellen, dass man bei Kunden wie dir ein dickes Fell braucht.

Autor: Michael G. (let)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal ganz dumm gefragt: Wie will man bei einer Architektur
mit Pipeline (beim SH2 immerhin 5-stufig) zyklengenau arbeiten?

Auch die Interruptlatenz ist zumindest beim SH2 nicht konstant.
Da könnte schonmal ein Flugzeug abstürzen.

Intel hat zumindest bis zum 486 noch Zyklen angegeben. Die waren
aber nicht konstant. Das dürfte bei jeder Pipeline Architektur so
sein. Die Ausführungszeiten der EU kann man noch angeben aber das
wars dann auch.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael G. schrieb:

> Mal ganz dumm gefragt: Wie will man bei einer Architektur
> mit Pipeline (beim SH2 immerhin 5-stufig) zyklengenau arbeiten?

Theoretisch kann man, solange man sich im Core bewegt und externe 
Einflüsse wie Synchronisationsverluste nicht berücksichtigen muss.

Man kann die Abhängigkeiten explizit angeben, beispielsweise wenn ein 
Folgebefehl ein soeben aus dem Speicher geladenes Register verwendet 
geht 1 Takt zusätzlich drauf, wenn es als Speicheradresse verwendet wird 
2 Takte usw. (ich beziehe mich hier nicht auf SH2).

Aber das wird recht bald sinnlos und sollte einem Simulator überlassen 
werden. Wie Robert schon sagt, das fehlerfrei hinzubekommen ist jenseits 
von einem Dutzend Befehlen wenig wahrscheinlich.

> Intel hat zumindest bis zum 486 noch Zyklen angegeben.

Intel und AMD geben auch heute noch Takte an, wobei Agner Fog 
detaillierter ist. Aber das sind nur noch grobe Hausnummern, denn 
einfach zusammenaddieren ist nicht annähernd richtig. Wenn man den 
kompletten Agner durch hat, mitsamt Aufdröselung der internen 
Architektur, dann ist man etwas schlauer.

> Die waren
> aber nicht konstant. Das dürfte bei jeder Pipeline Architektur so
> sein. Die Ausführungszeiten der EU kann man noch angeben aber das
> wars dann auch.

Wenn man genau weiss, wie diese Dinger intern arbeiten, dann geht auch 
mehr. Mit der offiziell verfügbaren Doku geht da allerdings nichts, die 
ist viel zu schwamming. Der olle K6 wurde gut dokumentiert (Buch, sowie 
in Patentschriften von AMD) und ist recht gut nachvollziehbar. Bei 
späteren Modellen wird's komplizierter.

Für K7/K8 liefert AMD einen ziemlich taktgenauen Trace-gestützten 
Pipeline-Simulator, der zumindest bei L1-Hits leidlich brauchbare 
Ergebnisse ausspuckt. Dieses Tool basiert auf jenem Simulator, mit dem 
AMD selbst im Vorfeld Varianten ausprobiert, d.h. er bildet die internen 
Vorgänge recht genau ab.

Aber klar ist auch: Eine Sprungvorhersage, wie sie AMD seit dem K6 
verwendet, ist aufgrund des potentiell riesigen Kontextes nur in 
einfachen Fällen einigermassen reproduzierbar.

Autor: 123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nabend

Danke für die Infos, auch wenn ich nicht der Threadstarter bin.

wenn ich den SAM7X / SAM7S  mit mehr als 30MHz betreibe im ARM mode,
könnte ich genauso nur die halbe Taktfrequenz nehmen, und hätte "fast" 
die gleiche leistung? (die SRAM / HWRegisterzugriffe mal unter den tisch 
fallen lassen)
Meine Begründung, ich muss den Flash bei mehr als 30 MHz mit einem 
Waitstate faren, unter 30Mhz one. Damit habe ich bei > 30Mhz nur die 
halbe flash leistung.

Im ThumbMode hingegen kann ich mehr CPU leistung erzielen, da THUMB nur 
16 bit / ARM 32 Bit Code ist. Ein Flash Zugriff 32 bit laden sollte, und 
somit 2 Thumb befehle in einem load. Wer jetzt hier genau 
zwischenspeichert, ist mir jetzt nicht ganz klar, ich nehm mal an, das 
ist das AHB Bus interface der CPU

Das ganze bringt jetzt aber nur dann mehr leistung im Thumb mode, 
solange immer 2 Thumb befehle "gepart" sind. Damit meine ich, das zu 
einem Abarbeitungs blockes 2*x Behele behöhren. ist es eine ungerade 
anzhal, muss geht einer verloren, da im zwischenspeicher der falsche 
befehl gespeichert ist.

Ich lieg doch damit richtig oder Falsh?

Ich habe in dieser betrachtung jetzt mal die schnelleren SRAM und 
Peripheral zugriffe absichtlich unterschlagen, genauso wie die ggf. 
existierenden Prioritätsprobleme und Kollisionen beim DMA vom Flash nach 
irgend wo hin.


ps. ein Abarebeitungsblock ist ein code fragment, das ohne sprung 
durchlaufen werden kann. Somit ein Block, in dem die ASM Befehle in 
aufsteigender reihenfolge abgearbeitet werden können. Jeder Sprung, 
Call, Loop, ret, iret, beendet somit so einen block.

pss. der SMA3X ist doch eigentlich pinkompatibel zum SAM7X oder? Die 
Leistungsbeurteilung ist da sicher noch eine ecke komplizierter, 2 
Busmaster für den M3, Cash, Multilayer AHB, 4 fach piplining, ...

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
123 schrieb:

> wenn ich den SAM7X / SAM7S  mit mehr als 30MHz betreibe im ARM mode,
> könnte ich genauso nur die halbe Taktfrequenz nehmen, und hätte "fast"
> die gleiche leistung?

Nicht ganz so krass. RAM-Zyklen sind weiterhin nur 1 Takt, d.h. ein 
Store-Befehl, der vorher 2 Takte brauchte, der braucht nun 3.

Wenn man es stellenweise eilig hat, dann kombiniert man Thumb-Code im 
Flash mit ARM-Code im RAM.

> Im ThumbMode hingegen kann ich mehr CPU leistung erzielen, da THUMB nur
> 16 bit / ARM 32 Bit Code ist.

Korrekt. Atmels SAM7 und Analog Devices ADUC7000 sind auf Thumb-Mode 
optimiert, ARM-Code im Flash mögen sie nicht so. Sieht bei LPC2000 
anders aus.

> zwischenspeichert, ist mir jetzt nicht ganz klar, ich nehm mal an, das
> ist das AHB Bus interface der CPU

Nope. 2 Stück 32-Bit breite Prefetch-Buffer vor dem Flash-ROM. Wird im 
Datasheet erwähnt.

> Das ganze bringt jetzt aber nur dann mehr leistung im Thumb mode,
> solange immer 2 Thumb befehle "gepart" sind.

Korrekt. Es ist deshalb auch hilfreich, wenn ein Sprungziel eine 
Wortadresse ist (MOD 4 = 0).

Autor: 123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nabend,

wir sollten einen x86 / x64 auch nicht mit einem ARM vergleichen.

Da sind sachen möglich, die will man gar nicht erst in einem ARM haben.

Sprungvorhersage: aufgrund der damals teilweise sehr langen Piplines, 
war jeder sprung ein "totalverlust" von n-x takten, da die pipline erst 
mal komplett neu gefüllt werden muss. ARM hat meines wissens nur eine 4 
stufige, da sind die verluste nicht ganz so dramatisch, bzw, arm hat das 
teilweise sehr geschickt gelöst. Mit den bedingungen, die man an jeden 
ARM befehl anhängen kann. Lieber 2 Zyklen verlieren, als die ganze 
pipline neu zu laden

Simultanes ausführen von Befehlen:
x86 CPUs bestehen selbst als Singelcore CPU aus mehren Rechenwerken, 
teilweise für verschiedene Aufgaben. Die CPU ist somit in der lage mehre 
Befehle quasi gleichzeitig auszuführen, WENN diese nicht von einander 
abhängig sind. auch unter paring bekannt. Bestimmte ASM Befehle können 
gleichzeitig mit anderen ausgeführt werden.

Umsortierung von Instruktionen zur Laufzeit
Das geht jetzt mitlerweile sogar so weit, das befehle, die nach einem 
anderem Befehl im Code stehen vorher ausgefürt werden, wenn die CPU 
feststellt, das dies möglich ist. Um eine bessere auslastung der 
rechenwerke zu erziehlen. (Alte Binaries waren nicht darauf optimiert 
und können dadurch schneller laufen)

Das ganze könnte man dann noch mit der Srpungvorhersage verknüpfen.
Berechnungen, die nach einer entscheidung durchgefurt werden, werden 
quasi gleichzeitig mit der berechnung der entscheidung selber 
durchgeführt. Es wird nach dem die Entscheidung berechnet wurde nur noch 
der Zweig weiterverfolgt, der auch berechnet wurde.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
123 schrieb:

> pss. der SMA3X ist doch eigentlich pinkompatibel zum SAM7X oder? Die
> Leistungsbeurteilung ist da sicher noch eine ecke komplizierter, 2
> Busmaster für den M3, Cash, Multilayer AHB, 4 fach piplining, ...

Die SAM3 kenne ich nicht, aber generell wird das bei wohl allen CM3 
komplizierter. Selbst der vergleichsweise einfache STM32 mit 64 Bit 
Flash-Interface ohne Branch Cache ist schon nicht so einfach zu 
kalkulieren. Immerhin sind Thumb2 Befehle auch mal 32-Bit lang und bei 2 
Waitstates für vollen Takt kann dem STM32 folglich auch die Puste 
ausgehen. Wobei das dank Prefetch bei üblichem 16/32-Bit Mix statistisch 
statistisch meist nicht allzu sehr auffallen wird, aber wenn man es 
drauf anlegt, dann schon.

Ansonsten ist die Pipeline-Kalkulation der CM3 zwar komplizierter, aber 
durchaus noch überschaubar.

Autor: 123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ A. K.
Danke für die Antwort.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
123 schrieb:

> wir sollten einen x86 / x64 auch nicht mit einem ARM vergleichen.
> Da sind sachen möglich, die will man gar nicht erst in einem ARM haben.

Eine ARM Controller jedenfalls. Die Cortex-A Serie ist in dieser 
Hinsicht näher an den x86ern dran.

> stufige, da sind die verluste nicht ganz so dramatisch, bzw, arm hat das
> teilweise sehr geschickt gelöst. Mit den bedingungen, die man an jeden
> ARM befehl anhängen kann.

Yep. Da war ARM sozusagen seiner Zeit weit voraus. Die einzige andere 
Architektur, die systematisch (und konsequenter) auf Predication setzt, 
ist aber schon wieder am absterben (IA64). Nachteil davon war allerdings 
eine erhebliche Verschwendung von Codespace, weshalb sich Konstanten 
schlecht zusammenbauen lassen - alle anderen 32bit RISC können 2 16-Bit 
Hälften kombinieren.

Thumb2 ist da geschickter konstruiert, Konstanten sind inline möglich 
und die Predication gibt's trotzdem, als codesparender Präfix.

> abhängig sind. auch unter paring bekannt.

Naja. Beim Pentium[MMX] nannte man das "pairing". Seit PentiumPro und 
tiefen Reordering müssen die nicht paarweise unabhängig sein.

> anderem Befehl im Code stehen vorher ausgefürt werden, wenn die CPU
> feststellt, das dies möglich ist.

Oder auch schon mal auf Verdacht, ohne das genau zu wissen, mit 
anschliessender Wiederholung wenn's in die Hose ging. Insbesondere der 
Pentium4 trieb da ziemliche Blüten.

> Das ganze könnte man dann noch mit der Srpungvorhersage verknüpfen.
> Berechnungen, die nach einer entscheidung durchgefurt werden, werden
> quasi gleichzeitig mit der berechnung der entscheidung selber
> durchgeführt.

Ist ja auch so, seit PentiumPro/K5/Nx586. Es wird auf Verdacht 
rücksichtslos weitergerechnet, bis ein irregeleiteter Sprung dran kommt 
und dem Treiben ein Ende setzt. Einzig Atom und ältere VIAs verzichten 
auf solche Mätzchen.

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
123 schrieb:
> Da sind sachen möglich, die will man gar nicht erst in einem ARM haben.

Schauen wir mal...

> Sprungvorhersage: aufgrund der damals teilweise sehr langen Piplines,

Statisch seit ARM10, dynamisch seit ARM11

> Simultanes ausführen von Befehlen:

Cortex-R4, Cortex-A8 und A9

> Umsortierung von Instruktionen zur Laufzeit

Eingeschränkt seit ARM11 (innerhalb der LS pipeline und zwischen LS und 
ALU/MAC). Beim C-A9 auch zwischen den ALU/MAC pipelines.

> Das ganze könnte man dann noch mit der Srpungvorhersage verknüpfen.
> Berechnungen, die nach einer entscheidung durchgefurt werden, werden
> quasi gleichzeitig mit der berechnung der entscheidung selber
> durchgeführt.

Wird doch durch die Sprungvorhersage für den angenommenen Pfad sowieso 
bewirkt. Wenn Du beide Zweige verfolgst, dann brauchst Du keine 
Sprungvorhersage mehr.

Gruß
Marcus

Autor: 123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin

was macht die CPU wenn es auf einaml zu viele pfade gibt? Mehr pfade als 
sie gleichzeitig berechnen kann?
Oder ist vom CPU Designe ausgeschlossen, das sowas überhaupt passieren 
kann?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
123 schrieb:

> was macht die CPU wenn es auf einaml zu viele pfade gibt? Mehr pfade als
> sie gleichzeitig berechnen kann?

Es wird nur ein Pfad verfolgt, nämlich der von der Sprungvorhersage 
vorhergesagte. Deshalb heisst die Sprungvorhersage so. ;-)

> Oder ist vom CPU Designe ausgeschlossen, das sowas überhaupt passieren
> kann?

So ist es. In kann mich an Konzepte erinnern, in der mehrere Pfade 
verfolgt werden, aber nicht an irgendwelche konkreten Implementierungen 
davon.

Ausnahme: Beim Instruction Fetch gibt es nicht selten Implementierungen, 
in denen kurzfristigst beide Wege verfolgt werden. Schon 68000 hatte 
dafür gesorgt, dass zum Zeitpunkt der Entscheidung eines kurzen 
Sprungbefehls beide Zielbefehle zur Verfügung standen (deshalb 
gleichermassen 10 Takte in beiden Fällen).

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
123 schrieb:
> was macht die CPU wenn es auf einaml zu viele pfade gibt? Mehr pfade als
> sie gleichzeitig berechnen kann?
> Oder ist vom CPU Designe ausgeschlossen, das sowas überhaupt passieren
> kann?

Bezog sich die Frage auf meinen Beitrag? Die CPU führt immer den einen 
Pfad aus, der von der Sprungvorhersage bestimmt wurde. Diese 
Instruktionen dann aber auf allen Pipelines, sofern es die 
Abhängigkeiten zulassen. Würden ohnehin beide Pfade ausgeführt, bräuchte 
ich ja keine Vorhersage mehr.

Vielleicht kann man in größeren Prozessoren noch was herausholen, indem 
man Pipelines reserviert und verschiedenen Pfaden zuordnet, aber bei der 
Klasse über die wir hier reden lohnt sich das wohl eher nicht. Wer weiß 
was das nächste ARM Flaggschiff bringt.

--
Marcus

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:

> So ist es. In kann mich an Konzepte erinnern, in der mehrere Pfade
> verfolgt werden, aber nicht an irgendwelche konkreten Implementierungen
> davon.

Ich erinnere mich wieder, wo ich das gelesen hatte. Suns "Rock" Projekt 
hatte sowas im Sinn. Wurde mit der Übernahme durch Oracle aber 
eingestampft.

Autor: 123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
auf was ich mich bezogen habe ist eigentlich das.

ich habe eine Verzweigung, kurz danach eine weitere. macht somit schon 4 
mögliche pfade. je länge der Pipline, umso mehr möglichkeiten, darin 
eine weitere verzweigung unterzubringen.

wobei immer noch der falback giblt, pipline neu füllen und alle 
vorhersagen wegschmeissen.

und wegen der Sprungvorhersage, da gab es doch auch noch den grund, die 
daten/Instruktionen vorab mal in den cash zu bekommen, bevor diese 
überhaupt angefordert werden.  im prinzip zur verkürzung der IO zeiten, 
da die CPU ja mitlerweile schneller rechnen kann als das speicher if 
daten liefern kann.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
123 schrieb:

> ich habe eine Verzweigung, kurz danach eine weitere. macht somit schon 4
> mögliche pfade.

Ich würde das anders formulieren: 4 Alternativen und 1 verfolgter Pfad.

Wobei der Pentium 4 in seinem Trace Cache den verfolgten Pfad speichert, 
auch wenn der aus allerlei verschiedenen Stücken Speicher stammt. Da mag 
es eine Grenze geben, aber ich kenne sie nicht. Die exakten Strategien 
dieses Trace Cache sind nicht bekannt.

> je länge der Pipline, umso mehr möglichkeiten, darin
> eine weitere verzweigung unterzubringen.

In diesem Sinn gibt es bei aktuellen Prozessoren keine Grenze, ausser 
der Kapazität der OoO-Engine, dem Reorder Buffer. Bei AMD sind das 24 
Befehlsgruppen (zu je 3 Befehlen). Da die Befehle zwar ungeordnet 
ausgeführt, aber in ihrer korrekten Reihenfolge abgeschlossen werden 
(retired) lässt sich jederzeit der korrekte Zustand wiederherstellen.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> 123 schrieb:
>
>> was macht die CPU wenn es auf einaml zu viele pfade gibt? Mehr pfade als
>> sie gleichzeitig berechnen kann?
>
> Es wird nur ein Pfad verfolgt, nämlich der von der Sprungvorhersage
> vorhergesagte. Deshalb heisst die Sprungvorhersage so. ;-)
>
>> Oder ist vom CPU Designe ausgeschlossen, das sowas überhaupt passieren
>> kann?
>
> So ist es. In kann mich an Konzepte erinnern, in der mehrere Pfade
> verfolgt werden, aber nicht an irgendwelche konkreten Implementierungen
> davon.
>
> Ausnahme: Beim Instruction Fetch gibt es nicht selten Implementierungen,
> in denen kurzfristigst beide Wege verfolgt werden. Schon 68000 hatte
> dafür gesorgt, dass zum Zeitpunkt der Entscheidung eines kurzen
> Sprungbefehls beide Zielbefehle zur Verfügung standen (deshalb
> gleichermassen 10 Takte in beiden Fällen).

Da muss ich widersprechen. Je nach Displacement (8-Bit/16-Bit) gibt es 
Unterschiede.
bcc (8-Bit displacement) 10 Zyklen taken, 8 Zyklen not taken
bcc (16-Bit displacement) 10 Zyklen taken, 12 Zyklen not taken
Beim dbcc waren es
cc true 12 Zyklen
cc false, 10 Zykeln bzw. 14 wenn der Counter abgelaufen war
(das kommt davon wenn man jahrelang Taktzyklen zählt, um die Routinen an 
die nötigen Tricks zum "Erhöhen der Auflüsung" anzupassen)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arc Net schrieb:

>> der Entscheidung eines kurzen Sprungbefehls

> Da muss ich widersprechen. Je nach Displacement (8-Bit/16-Bit) gibt es
> Unterschiede.

Und wie kriegst du ein 16-bit Displacement in einen kurzen Sprungbefehl 
rein?

> bcc (8-Bit displacement) 10 Zyklen taken, 8 Zyklen not taken

Ok, stimmt. Sequentiell war ein bischen fixer. Bei der Konkurrenz waren 
ausgeführte Sprünge allerding sehr viel teurer als nicht ausgeführte, 
bei 68000 war der Unterschied gering.

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.