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
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.
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=/com.arm.doc.faqs/4160.html
Das sollte schon mal weiterhelfen.
Viel Spass, Robert
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
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
>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)
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.
>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.
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.
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.
>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 ???
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.
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.
>- 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.ä.
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.
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
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.
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
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 )
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.
> 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.)
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
>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.
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.
@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
>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
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.
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.
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, ...
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).
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.
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.
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.
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
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?
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).
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
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.
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.
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.
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)
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.
