ich hatte einige umstimigkeiten mit der geschwindigkeit in der die grundrechenarten in kombination mit verschiedenen Datentypen ausgefürt werden. Ich habe daswegen alles mal im Bascom Simulator getestet(ohne Gewähr)
Die Komentare in der jeweiligen zeile sind nach Simulator die benötigten zyklen die für die berechnung benötigt werden. Mir hat es geholfen und deswegen wolte ich die ganze mühe nicht für mich behalten.Code:$regfile = "m32def.dat" $crystal = 11059200 Dim B1 As Byte Dim B2 As Byte Dim B3 As Byte Dim I1 As Integer Dim I2 As Integer Dim I3 As Integer Dim W1 As Word Dim W2 As Word Dim W3 As Word Dim L1 As Long Dim L2 As Long Dim L3 As Long Dim S1 As Single Dim S2 As Single Dim S3 As Single Dim D1 As Double Dim D2 As Double Dim D3 As Double B1 = 80 I1 = 80 W1 = 80 L1 = 80 S1 = 80 D1 = 80 B2 = 8 I2 = 8 W2 = 8 L2 = 8 S2 = 8 D2 = 8 Do B3 = B1 + B2 '9 B3 = B1 - B2 '9 B3 = B1 * B2 '10 B3 = B1 / B2 '112 Shift , B1 , Right , 3 '27 I3 = I1 + I2 '20 I3 = I1 - I2 '20 I3 = I1 * I2 '39 I3 = I1 / I2 '291 Shift , I1 , Right , 3 '34 W3 = W1 + W2 '20 W3 = W1 - W2 '20 W3 = W1 * W2 '39 W3 = W1 / W2 '255 ' Shift , W1 , Right , 3 '34 L3 = L1 + L2 '41 L3 = L1 - L2 '41 L3 = L1 * L2 '87 L3 = L1 / L2 '787 Shift , L1 , Right , 3 '48 S3 = S1 + S2 '162 S3 = S1 - S2 '171 S3 = S1 * S2 '420 S3 = S1 / S2 '527 Shift , S1 , Right , 3 '73 D3 = D1 + D2 '315 D3 = D1 - D2 '378 D3 = D1 * D2 '455 D3 = D1 / D2 '1760 Shift , D1 , Right , 3 '1 Loop End 'end program
Hallo mycroc,
schöne Liste, man glaubt ja nicht, wieviel so eine Division frißt.
Kannst du auch mal Words und Bytes miteinander verrechnen?
Ich hab mal Wurzeln aus Long Variablen gezogen, fast immer 2126 Takte:
http://www.team-iwan.de/technik/software/lcd03.php
Gruß, Michael
Ein Zyklus ??Code:Shift , D1 , Right , 3 '1
mfg robert
Wer glaubt zu wissen, muß wissen, er glaubt.
Hallo, Alle,
aus meinen Anfängen zur Aerodynamik auf eher gefestigten theoretischen Grundlagen habe ich einen Hang zur praktischen Überprüfung von Simulationen. Manchmal reicht mir dann auch die praktische Prüfung. Daher hatte ich vor einiger Zeit folgendes gemacht:
- Schalte LED1 ein (meist nur bei "Handstoppung")
- Schleifenanfang (z.B. für 1000 Schleifen oder bei Oszilloskopmessungen auch unbegrenzt)
- Schalte LED2 ein
- Rechne eine bestimmte Rechnung
- Schalte LED2 aus
- Warte eine GENAU definierte Zeit (z.B. 1000 nops)
- Schleifenende
- Schalte LED1 aus (meist nur bei "Handstoppung")
Die benötigte Zeit für die bestimmte Rechnung hatte ich anhand der Schaltvorgänge der LED´s mit dem Oszilloskop gemessen (dann reichen auch weniger nops). Die andere, bei mir ebenfalls erfolgreiche, Möglichkeit war einen bestimmte Anzahl Rechnungen durchzuführen und die LED1 vor Eintritt in die Schleife einzuschalten und nach Austritt aus der Schleife auszuschalten - die Zeit wird händisch gestoppt. Die ähnliche Messung aber OHNE Rechnung liefert dann den Zeitbedarf für den Schleifen-Overhead ohne Rechnung. Aus dem Vergleich der beiden Werte errechne ich mir den Zeitbedarf für die entsprechende Rechnung bzw. Subroutine.
Auf diese Weise hatte ich auch ganze Subroutinen ausgemessen. Das Ergebnis scheint durch die meist recht gute Funktion meiner ziemlich Interrupt-durchseuchten Projektchen bestätigt zu werden.
Ciao sagt der JoeamBerg
Das mit der Kurzen Zeit für ein shift bei Flißkomma zahlen kann schon sein. Schließlich braicht man dazu nur den Exponenten (1 Byte ?) zu erniedriegen. Wenn die zahl schon in Registen ist reicht dazu tatsachlich ein subi r?, 3. Im Vergleich zu Byte + Byte, würde ich aber sagen da ist ein Tippfehler drin.
Viele Compiler haben keine extra Routinen für gemischte Operationen (z.B. Word + byte), statt desen wird erst auf den größeren (oder vom Ziel ?) Typ erweitert. Da wäre noch etwas Raum für Optimierungen.
Bei Bascom ist die Zeit ja noch einigermaßen eindeutig (nur eine Operation je Zeile), bei anderen Compilern kann die Zeit ja nach Context etwas variieren.
bei anderen Compilern kann die Zeit ja nach Context etwas variieren.
Ja, bei WinAVR wir es noch schneller und der Compilercode ist kürzer.
Probier es selber mal aus.
mfg
WinAVR ist so ein Beispiel, wo die Werte nicht jedes mal aus dem RAM gehohlt werden. Das kann je Byte etwa 3-6 Zyklen sparen, dazu noch ein Bisschen durch mehr inline Code. Gerade die langsamen Dinge sollten aber ähnlich sein. Nur bei der Wurzel gibte es ganz verschiedene Methoden die zu berechnen und entsprechend möglicherweise große unterschiede.
Wenn es noch jemanden interessiert, ich konnte das Mysterium mit diesem "1-cycle-shift right" klären:
Bascom 1.11.8.1 meckert den Shift -Befehl an (weil ihm die Variable nicht passt)
Bascom 1.11.9.2 meckert NICHT, sondern lässt den Befehl einfach aus !
Bei "Shift , D1 , Right , 3"
lädt er zwar noch r25 mit "3"
( LDI r25,0x03 --> 1 Cycle )
aber das wars's dann auch.
Ich habe mir das Programm von @mycroc übersetzt und disassembliert, weil mir die Sache seltsam vorkam, der relevante Ausschnitt ist oben.Code://----------D3 = D1 / D2 '1760 LDI XL,0x9F D3 LDI XH,0x00 ST -Y,XH ST -Y,XL LDI XL,0x97 D2 LDI XH,0x00 LDI ZL,0x87 D1 LDI ZH,0x00 CALL L_0x06A4 ADIW YL,0x0002 //------------------Shift , D1 , Right , 3 '1 LDI r25,0x03 ????? JMP L_0x011E //LOOP: .DB 0xF8, 0x94 ;.. L_0x03FE: //END RJMP L_0x03FE .DB 0x09, 0xD0, 0x0E, 0x94, 0xE5, 0x04 ;......
Wenn jemand das komplette Assembler-listen sehen will, --> sprechen
mfg robert
Wer glaubt zu wissen, muß wissen, er glaubt.
Sehr interessante Analyse.
Wieviele Zyklen benötigen eigentlich Sinus und Cosinus?
Habs grad ausprobiert: laut meinem Simulator (Bascom 1.11.9.3) benötigt ein Sinus-Aufruf 85 Zyklen, beim Cosinus bzw. Tangens sinds 85 bzw. 115 Zyklen.
Mich würde ja interessieren, wie Bascom das übersetzt, sprich, wie der Controller die Funktionswerte dann auch berechnet. Wird ihm da eine feste Tabelle mitgegeben, oder errechnet er sich die Werte mit Reihenentwicklungen o.ä.?
Viele Grüße
Berechtigungen
Zitieren
Lesezeichen