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
Schau mal auf arm.com. Da gibts irgendwo ne pdf mit dem Befehlssatz (arm7tdmi).
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.
Messen. Über einen Timer den Sysclock zählen, dann weiß Du das ganz genau. Ohne mühsames Studium der Doku.
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
Nuja... Robert hat m.W. solche Datasheets geschrieben. Ich könnte mir vorstellen, dass man bei Kunden wie dir ein dickes Fell braucht.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.