AVR Embedded - wo finde ich die Implementierung?

[Timm Thaler]

Bei der Multiplikation größerer Zahlen baut der Compiler statt der nativen mul-Befehle einen Aufruf von fpc_mul_dword oder fpc_mul_longint ein. Allerdings sind die Routinen sehr langsam und sehr speicherfressend.

Nun hab ich mir das mal im Disassembler angesehen, und tatsächlich scheint mir das extrem ineffizient, es wird alles in einer Schleife durchgezogen statt die nativen mul-Befehle zu verwenden.

Wo finde ich denn die Implementierung des Codes für fpc_mul_dword, fpc_mul_longint und so? Ich finde nur die Deklaration in compproc.inc. Ich würde mir gern mal ansehen, ob man da für AVR etwas optimieren kann.

Code: Alles auswählen

17e:   df 93          push   r29
 180:   cf 93          push   r28
 182:   1f 93          push   r17
 184:   0f 93          push   r16
 186:   ff 92          push   r15
 188:   ef 92          push   r14
 18a:   cf 92          push   r12
 18c:   bf 92          push   r11
 18e:   af 92          push   r10
 190:   9f 92          push   r9
 192:   8f 92          push   r8
 194:   7f 92          push   r7
 196:   6f 92          push   r6
 198:   5f 92          push   r5
 19a:   4f 92          push   r4
 19c:   3f 92          push   r3
 19e:   2f 92          push   r2
 1a0:   cd b7          in   r28, 0x3d   ; 61
 1a2:   de b7          in   r29, 0x3e   ; 62
 1a4:   c8 50          subi   r28, 0x08   ; 8
 1a6:   d0 40          sbci   r29, 0x00   ; 0
 1a8:   0f b6          in   r0, 0x3f   ; 63
 1aa:   f8 94          cli
 1ac:   de bf          out   0x3e, r29   ; 62
 1ae:   0f be          out   0x3f, r0   ; 63
 1b0:   cd bf          out   0x3d, r28   ; 61
 1b2:   6f 83          std   Y+7, r22   ; 0x07
 1b4:   17 2f          mov   r17, r23
 1b6:   f8 2e          mov   r15, r24
 1b8:   e9 2e          mov   r14, r25
 1ba:   61 2d          mov   r22, r1
 1bc:   71 2d          mov   r23, r1
 1be:   81 2d          mov   r24, r1
 1c0:   91 2d          mov   r25, r1
 1c2:   a1 e0          ldi   r26, 0x01   ; 1
 1c4:   ca 2e          mov   r12, r26
 1c6:   b1 2c          mov   r11, r1
 1c8:   a1 2c          mov   r10, r1
 1ca:   61 2c          mov   r6, r1
 1cc:   af ef          ldi   r26, 0xFF   ; 255
 1ce:   aa 83          std   Y+2, r26   ; 0x02
 1d0:   8a 80          ldd   r8, Y+2   ; 0x02
 1d2:   83 94          inc   r8
 1d4:   8a 82          std   Y+2, r8   ; 0x02
 1d6:   cb 82          std   Y+3, r12   ; 0x03
 1d8:   9b 2c          mov   r9, r11
 1da:   2a 2c          mov   r2, r10
 1dc:   86 2c          mov   r8, r6
 1de:   0b 81          ldd   r16, Y+3   ; 0x03
 1e0:   02 23          and   r16, r18
 1e2:   0b 83          std   Y+3, r16   ; 0x03
 1e4:   93 22          and   r9, r19
 1e6:   24 22          and   r2, r20
 1e8:   85 22          and   r8, r21
 1ea:   0b 81          ldd   r16, Y+3   ; 0x03
 1ec:   01 15          cp   r16, r1
 1ee:   91 04          cpc   r9, r1
 1f0:   21 04          cpc   r2, r1
 1f2:   81 04          cpc   r8, r1
 1f4:   a1 f0          breq   .+40        ;  0x21e
 1f6:   36 2e          mov   r3, r22
 1f8:   47 2e          mov   r4, r23
 1fa:   58 2e          mov   r5, r24
 1fc:   79 2e          mov   r7, r25
 1fe:   8f 80          ldd   r8, Y+7   ; 0x07
 200:   28 2c          mov   r2, r8
 202:   81 2e          mov   r8, r17
 204:   9f 2c          mov   r9, r15
 206:   ee 82          std   Y+6, r14   ; 0x06
 208:   26 0e          add   r2, r22
 20a:   87 1e          adc   r8, r23
 20c:   98 1e          adc   r9, r24
 20e:   0e 81          ldd   r16, Y+6   ; 0x06
 210:   09 1f          adc   r16, r25
 212:   0e 83          std   Y+6, r16   ; 0x06
 214:   62 2d          mov   r22, r2
 216:   78 2d          mov   r23, r8
 218:   89 2d          mov   r24, r9
 21a:   2e 80          ldd   r2, Y+6   ; 0x06
 21c:   92 2d          mov   r25, r2
 21e:   8f 80          ldd   r8, Y+7   ; 0x07
 220:   28 2c          mov   r2, r8
 222:   81 2e          mov   r8, r17
 224:   9f 2c          mov   r9, r15
 226:   ed 82          std   Y+5, r14   ; 0x05
 228:   22 0c          add   r2, r2
 22a:   88 1c          adc   r8, r8
 22c:   99 1c          adc   r9, r9
 22e:   0d 81          ldd   r16, Y+5   ; 0x05
 230:   00 1f          adc   r16, r16
 232:   0d 83          std   Y+5, r16   ; 0x05
 234:   2f 82          std   Y+7, r2   ; 0x07
 236:   18 2d          mov   r17, r8
 238:   f9 2c          mov   r15, r9
 23a:   2d 80          ldd   r2, Y+5   ; 0x05
 23c:   e2 2c          mov   r14, r2
 23e:   2c 2c          mov   r2, r12
 240:   8b 2c          mov   r8, r11
 242:   9a 2c          mov   r9, r10
 244:   6c 82          std   Y+4, r6   ; 0x04
 246:   22 0c          add   r2, r2
 248:   88 1c          adc   r8, r8
 24a:   99 1c          adc   r9, r9
 24c:   0c 81          ldd   r16, Y+4   ; 0x04
 24e:   00 1f          adc   r16, r16
 250:   0c 83          std   Y+4, r16   ; 0x04
 252:   c2 2c          mov   r12, r2
 254:   b8 2c          mov   r11, r8
 256:   a9 2c          mov   r10, r9
 258:   2c 80          ldd   r2, Y+4   ; 0x04
 25a:   62 2c          mov   r6, r2
 25c:   0a 81          ldd   r16, Y+2   ; 0x02
 25e:   0f 31          cpi   r16, 0x1F   ; 31
 260:   08 f4          brcc   .+2         ;  0x264
 262:   b6 cf          rjmp   .-148       ;  0x1d0
 264:   c8 5f          subi   r28, 0xF8   ; 248
 266:   df 4f          sbci   r29, 0xFF   ; 255
 268:   0f b6          in   r0, 0x3f   ; 63
 26a:   f8 94          cli
 26c:   de bf          out   0x3e, r29   ; 62
 26e:   0f be          out   0x3f, r0   ; 63
 270:   cd bf          out   0x3d, r28   ; 61
 272:   2f 90          pop   r2
 274:   3f 90          pop   r3
 276:   4f 90          pop   r4
 278:   5f 90          pop   r5
 27a:   6f 90          pop   r6
 27c:   7f 90          pop   r7
 27e:   8f 90          pop   r8
 280:   9f 90          pop   r9
 282:   af 90          pop   r10
 284:   bf 90          pop   r11
 286:   cf 90          pop   r12
 288:   ef 90          pop   r14
 28a:   ff 90          pop   r15
 28c:   0f 91          pop   r16
 28e:   1f 91          pop   r17
 290:   cf 91          pop   r28
 292:   df 91          pop   r29
 294:   08 95          ret
 

[Mathias]

ATtiny oder ATmega ?

[Timm Thaler]

ATmega natürlich. Dass die Tinys üblicherweise keinen Hardware-mul haben ist mir schon klar.

Ich hab jetzt in einer BME280-Berechnung (Drucksensor von Bosch, liefert ADC-Werte, übelst aufwendig daraus die physikalischen Werte zu berechnen) von FPC-Multiplikation auf eigene ASM-Multiplikation und Division umgebaut - und das Programm braucht 8kB Speicher weniger.

[af0815]

Kannst du für das immer ein minimal Beispiel in Lazarus/FPC machen. Man kann es damit leichter nachvollziehen und auch das ganze dann in den Bugtracker oder Mailingliste geben. Weil mit dem Projekt ist auch komplett klar was du an Einstellungen verwendet hast. Und bei AVR gehe ich sowieso davon aus, das du den aktuellsten Trunk verwendest.

[Timm Thaler]

Naja, ich würde gern erstmal geklärt haben, nach welchen Kriterien hier programmiert wurde. Ich persönlich verwende einige Optimierungen:

1. Man kann Multiplikation deutlich verkürzen, wenn man zwei 16bit-Ints zu einem 32bit-Int verrechnet. Und oft ist das ja der Fall: Man hat einen ADC-Wert mit 12bit und einen Umrechnungsfaktor mit 14bit, multipliziert das zu 26bit und teilt durch 1024 (10bit). Da reicht es, wenn 16bit x 16bit zu 32bit werden und nach dem div 1024 wieder 16bit rauskommen.

Der Compiler bläst aber erstmal die 16bit auf 32bit auf und rechnet das komplett in 32bit durch. Ist wahrscheinlich so die "saubere" Vorgehensweise, benötigt aber einen erheblichen Overhead, der auf dem PC nicht stört, auf dem AVR schon.

2. Division auf dem AVR geht ja immer nur in Software. Will ich eine 32bit-Zahl durch 10 teilen, benötige ich dafür eine Schleife mit 8 Durchläufen, da 10 in 8bit passt. (Wenn ich das noch optimiere, benötige ich nur 4 Durchläufe, da 10 auch in 4bit passt. )

Der Compiler macht aber immer aus der 10 einen 32bit-Wert und ruft eine 32bit-Division auf - und die braucht 32 Durchläufe, und über 4 Byte Dividend, benötigt also deutlich mehr als 4mal so lange.

Derartige Optimierungen wird man aber auf dem PC nicht wollen, und es kann sein, dass man hier versucht die Variablenbehandlung mit dem PC konsistent zu halten: Integer werden immer auf gemeinsame Breite oder die nächstgrößere erweitert. Und deswegen weniger effizienten Code in Kauf nimmt.

Das fällt auch normalerweise nicht auf, aber ich hab jetzt eine kleine Gewächshaussteuerung auf dem ATmega328, da werden eben ein paar Werte verrechnet, einige Sensoren ausgewertet, fürs Display die Werte aufbereitet - und schwupps ist der Speicher alle. Nachdem ich die Muls und Divs durch meine eigenen Routinen ersetzt habe, war 1/3 des Speichers wieder frei. Das haut schon ordentlich rein.

[Socke]

Wo finde ich denn die Implementierung des Codes für fpc_mul_dword, fpc_mul_longint und so? Ich finde nur die Deklaration in compproc.inc. Ich würde mir gern mal ansehen, ob man da für AVR etwas optimieren kann.

Die Implementierung findest du in <fpcsrc>/rtl/inc/generic.inc. Diese sind plattformunabhänging in Pascal geschrieben und können somit überall verwendet werden. Plattformspezifische Implementierungen gehören wohl in <fpcsrc>/rtl/avr/math.inc.

[af0815]

Mit Beispielen, kann man das sicher in der Mailingliste erfragen bzw. die Hintergründe bekommen, deswegen das mit 'mikro' Beispielen. Es wird beim Compiler sehr wohl zwischen den Plattformen unterschieden, nur ist die AVR Plattform nicht so verbreitet. Deswegen auch nicht wirklich ein starker Fokus darauf.

Der Sensor schaut ja recht interessant aus, allerdings verstehe ich jetzt was der dir für Kopfzerbrechen bei der Berechnung macht

[Timm Thaler]

Der Sensor schaut ja recht interessant aus, allerdings verstehe ich jetzt was der dir für Kopfzerbrechen bei der Berechnung macht

Der Sensor ist genial, vor allem weil er Temp, RH und Druck liefert. Die Auflösung, die er liefert brauche ich bei weitem nicht, der kann ja auch Höhenmessung über Druck. Wenn Du die Berechnung siehst, wird da auch viel mit div N gearbeitet, was der Compiler zu einem Shift right macht, oft mit Vorzeichenprüfung. Das geht zwar schnell, frisst in der Summe aber ordentlich Speicher. Also hab ich auch noch eine Funktion div2^n gemacht, die das Geshifte an einer Stelle zusammenfasst. Dauert etwas länger, weil jedesmal Funktionsaufruf, aber spart unheimlich Speicherplatz. Nun müsste ein Compiler entscheiden: Will er lieber Speicher sparen, oder will er schnell sein?

Pascal ist kann bei der Berechnung Überraschungen enthalten, weil es unsigned int und signed int nicht gleich behandelt. Zum Beispiel wird ein uint16 x int16 mit 32 bit gerechnet, ein int16 x int16 aber nur mit 16 Bit. Da kannst Du böse auf die Nase fliegen. Beispiel:

Spannung(int16) := ADC-Wert(uint16) * Konstante(wird als int16 behandelt) div 16384 => funktioniert, weil zwischendurch mit 32 Bit gerechnet wird.

Aber:

Mittelwert(int16) := Mittelwertfunktion(Mittelwert(int16), ADC-Wert(uint16))
Spannung(int16) := Mittelwert(int16) * Konstante(wird als int16 behandelt) div 16384 => funktioniert nicht, weil zwischendurch nur mit 16 Bit Bit gerechnet wird.

Andererseits kann man, wenn man auf uint32 castet für eine Berechnung ganz schnell bei einer 64-Bit Multiplikation landen.

Das ist historisch so gewachsen und entspricht irgendwie auch den Compilerrichtlinien für den Umgang mit Variablen, aber so richtig schön isses nicht.