mikrocontroller.net

Forum: Compiler & IDEs Hardware-Multiplier auf Mega32 ungenutzt?


Autor: Hundertvolt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...jetzt wundert mich der GCC aber gewaltig.

Übersetzt der den Befehl:
Calc *= H_SENS_MUL;

(zur Info: Calc ist ein unsigned short int, H_SENS_MUL eine 
#define-Konstante mit in diesem Fall dem Wert 15)


...zu diesem hier:
    Calc *= H_SENS_MUL;
 642:  c9 01         movw  r24, r18
 644:  44 e0         ldi  r20, 0x04  ; 4
 646:  88 0f         add  r24, r24
 648:  99 1f         adc  r25, r25
 64a:  4a 95         dec  r20
 64c:  e1 f7         brne  .-8        ; 0x646 <H_Sens_Read+0x84>
 64e:  82 1b         sub  r24, r18
 650:  93 0b         sbc  r25, r19

Also wohl die Multiplikation durch eine Additionsschleife.

Warum setzt er nicht den Hardware-Multiplier vom ATMega32 mit dem 
MUL-Befehl ein? Das sollte doch mit 16bit-Variablen schrittweise, 
Register für Register genauso wie eine Addition möglich sein und 
deutlich weniger Zyklen brauchen!

Wie bring ich ihn dazu, den MUL zu nehmen?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hundertvolt schrieb:
>
>     Calc *= H_SENS_MUL;
>  642:  c9 01         movw  r24, r18
>  644:  44 e0         ldi  r20, 0x04  ; 4
>  646:  88 0f         add  r24, r24
>  648:  99 1f         adc  r25, r25
>  64a:  4a 95         dec  r20
>  64c:  e1 f7         brne  .-8        ; 0x646 <H_Sens_Read+0x84>
>  64e:  82 1b         sub  r24, r18
>  650:  93 0b         sbc  r25, r19
> 
>
> Also wohl die Multiplikation durch eine Additionsschleife.

Schon.
Aber die Schleife wird nur 4 mal durchlaufen.

> Warum setzt er nicht den Hardware-Multiplier vom ATMega32 mit dem
> MUL-Befehl ein?

Wal das bei einer 16*16 Bit Multiplikation auch schon ziemlicher Aufwand 
mit Zwischenergebnissen und deren Addition bedeutet. Ganz zu schweigen 
davon, dass die entsprechenden Register auch freigeschaufelt werden 
müssen.

> Das sollte doch mit 16bit-Variablen schrittweise,
> Register für Register genauso wie eine Addition möglich sein und
> deutlich weniger Zyklen brauchen!

Ich denke, du kannst dich darauf verlassen, dass derjenige, der den 
Compiler konfiguriert hat, schon die richtige Zyklenzahl für einen MUL 
eingegeben hat. Und in diesem Fall ist es eben schneller, den MUL nicht 
zu benutzen.

Autor: Hundertvolt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Okay, Danke so weit!!

Wollte halt sicher gehen, dass ich nicht irgendwo etwas vergessen habe 
einzustellen und nur deshalb da kein MUL benutzt wird.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hmmm... für den Testfall
unsigned short mal15 (unsigned short a)
{
    return a*15;
}

bekomme ich mit -O2
mal15:
  mov r18,r24   ;  25  *movhi/1  [length = 2]
  mov r19,r25
  swap r18   ;  30  *ashlhi3_const/5  [length = 6]
  swap r19
  andi r19,0xf0
  eor r19,r18
  andi r18,0xf0
  eor r19,r18
  sub r18,r24   ;  8  subhi3/1  [length = 2]
  sbc r19,r25
  mov r24,r18   ;  22  *movqi/1  [length = 1]
  mov r25,r19   ;  23  *movqi/1  [length = 1]
  ret   ;  28  return  [length = 1]

und mit -Os
mal15:
  ldi r22,lo8(15)   ;  8  *movhi/4  [length = 2]
  ldi r23,hi8(15)
  rcall __mulhi3   ;  9  *mulhi3_call  [length = 1]
  ret   ;  30  return  [length = 1]

Für Optimierung auf Größe dürfte das unschlagbar sein (wenn man mehr als 
ein Aufruf von __mulhi3 im Code hat. Aber das kann gcc nicht global 
wissen, da er immer nur modulweise sieht) -- bis auf die Tatsache, daß 
in avr-gcc noch keine Tail-Calls drine sind (rcall+ret = rjmp)

Die Optimierung nach Speed sieht auch verdächtig flott aus (12 Ticks), 
da dürfte ne "normale" Multiplikation kaum mitkommen...

Johann

p.s. seltsamerweise wird's mit -O2 für den ATmega32 schlechter, 
nämlich 16 Ticks (oben war nur -mmcu=avr2 gesagt)
mal15:
  movw r18,r24   ;  27  *movhi/1  [length = 1]
  lsl r18   ;  35  *ashlhi3_const/2  [length = 2]
  rol r19
  add r18,r24   ;  8  *addhi3/1  [length = 2]
  adc r19,r25
  movw r20,r18   ;  28  *movhi/1  [length = 1]
  lsl r20   ;  34  *ashlhi3_const/4  [length = 4]
  rol r21
  lsl r20
  rol r21
  add r20,r18   ;  10  *addhi3/1  [length = 2]
  adc r21,r19
  movw r24,r20   ;  33  *movhi/1  [length = 1]
  ret   ;  31  return  [length = 1]

Die Kostenberechnung in GCC ist eben manchmal etwas esotherisch...

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:

> Die Optimierung nach Speed sieht auch verdächtig flott aus (12 Ticks),
> da dürfte ne "normale" Multiplikation kaum mitkommen...

9 Takte und funktioniert bei jedem uint8 Multiplikator:
    ldi   r31, 15
    mul   r25, r31
    mov   r25, r0
    mul   r24, r31
    add   r25, r1
    mov   r24, r0
    clr   r1
    ret

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:

> 9 Takte und funktioniert bei jedem uint8 Multiplikator:

GCC kann aber nur Multiplikanden gleicher Breite multiplizieren.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aber er kann erkennen, dass einer der beiden Operanden eine Konstante 
0..255 ist. Sowas macht er ja an beliebig vielen Stellen.

Nur ist möglicherweise die Kostenkalkulation der mul vs. shift/add/sub 
Optimierung nicht sonderlich abhängig von der Zielmaschine. Geht 
vielleicht sogar davon aus, dass alles was heute rumschwirrt einen 
Barrel-Shifter hat und für int/unsigned nur einen Befehl braucht.

Und wenn diese "Optimierung" mittendrin erst einmal vollbracht ist, dann 
kann auch das beste Backend das nicht mehr gerade biegen.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Johann L. schrieb:
>
>> Die Optimierung nach Speed sieht auch verdächtig flott aus (12 Ticks),
>> da dürfte ne "normale" Multiplikation kaum mitkommen...
>
> 9 Takte und funktioniert bei jedem uint8 Multiplikator:
>
>
>     ldi   r31, 15
>     mul   r25, r31
>     mov   r25, r0
>     mul   r24, r31
>     add   r25, r1
>     mov   r24, r0
>     clr   r1
> 

Ok, überzeugt :-)

Bau's ein in avr-gcc:

1) mulhi3 akzeptiert nicht nur GPRs, sondern auch Konstanten
2) die Konstante kommt per copy_to_mode_reg in ein GPR und man
   expandiert je nach HI zum alten *mulhi3_enh oder für QI zu einer
3) Neue Insn *mulhi3_enh_zerox
(define_insn "*mulhi3_enh_zerox"
  [(set (match_operand:HI 0 "register_operand" "=&r")
        (mult:HI (match_operand:HI 1 "register_operand" "r")
                 (zero_extend:HI (match_operand:QI 2 "register_operand" "r"))))]
  "AVR_HAVE_MUL"
  ...

Ich hab kein FSF assignment, würd also nix bringen wenn ichn Patch 
machen würd.

Johann

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:

> Ich hab kein FSF assignment, würd also nix bringen wenn ichn Patch
> machen würd.

Naja, das kannste aber ruhig mal machen, gemessen daran, dass du
einigermaßen Durchblick da hast.  Ist für einen Deutschen übrigens
komplett risikofrei :), wir können nämlich aus Prinzip ein Copyright
niemandem abtreten.  Wenn's die FSF also glücklich macht...

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Johann L. schrieb:
>
>> Ich hab kein FSF assignment, würd also nix bringen wenn ichn Patch
>> machen würd.
>
> Naja, das kannste aber ruhig mal machen, gemessen daran, dass du
> einigermaßen Durchblick da hast.  Ist für einen Deutschen übrigens
> komplett risikofrei :), wir können nämlich aus Prinzip ein Copyright
> niemandem abtreten.  Wenn's die FSF also glücklich macht...

Meine anderen Patches gammeln auch nur in irgendwelchen MLs rum, ausser 
für
   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18145
den hat Eric glaub in seiner Win-Distri drinne, aber in mainline ist er 
auch nicht.

Heisst konkret: wenn die FSF es irgendwann mal gebacken bekommt, kann 
man die ganzen Patches nochmal komplett neu schreiben weil man sie gegen 
trunk haben will und mit den olle Kamellen kaum mehr was anfangen kann. 
Also doppelte Arbeit, was ich nicht einsehe.

Eric hatte mal angedeutet, daß die FSF nicht sooo flott ist. Er wartet 
immerhin schon rund 3 Jahren oder so...

Johann

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:

> Eric hatte mal angedeutet, daß die FSF nicht sooo flott ist. Er wartet
> immerhin schon rund 3 Jahren oder so...

Nein, die FSF ist da so lahm nicht.  Meine ,Assignments' damals haben
trotz des Postwegs alles in allem keine 2 Monate gebraucht.  Wenn du
das also mal machen willst, damit deine Patches denn auch eine Chance
haben, überhaupt in den Code einzufließen (ein wenig ,,Durchboxen''
muss man das dann trotzdem noch), dann sollstest du diesen Kram mal
anschieben.

Was bei Eric gedauert hat (und wohl immer noch dauert) ist, all diesen
Kram durch die Rechtsabteilung bei Atmel zu bekommen, damit die erstmal
zustimmen, dass für ihn und seine Kollegen das FSF copyright assignment
überhaupt erst beantragt werden darf.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Johann L. schrieb:
>
>> Eric hatte mal angedeutet, daß die FSF nicht sooo flott ist. Er wartet
>> immerhin schon rund 3 Jahren oder so...
>
> Nein, die FSF ist da so lahm nicht.  Meine ,Assignments' damals haben
> trotz des Postwegs alles in allem keine 2 Monate gebraucht.  Wenn du
> das also mal machen willst, damit deine Patches denn auch eine Chance
> haben, überhaupt in den Code einzufließen (ein wenig ,,Durchboxen''
> muss man das dann trotzdem noch), dann sollstest du diesen Kram mal
> anschieben.

Das war Anfang Januar. Angeblich wollten sie was schicken.
Als nach über 3 Monaten noch nix angekommen war, hab ich mal vorsichtig 
nachgefragt...keine Antwort. Soviel zu dem Thema.

> Was bei Eric gedauert hat (und wohl immer noch dauert) ist, all diesen
> Kram durch die Rechtsabteilung bei Atmel zu bekommen, damit die erstmal
> zustimmen, dass für ihn und seine Kollegen das FSF copyright assignment
> überhaupt erst beantragt werden darf.

Ok, wenn das Dummheit von Atmel ist, selber Schuld.
Mit den Worten von Onkel Wicki:

>> [...] and chip manufacturers today consider a gcc port almost
>> essential to the success of an architecture.

Johann

Autor: Johann L. (gjlayde) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier ist das Patch. Vielleicht kannst du ja was damit anfangen...

Johann

Autor: Martin Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Finde es schade, dass zumindest einige von Georg-Johann L.s 
Verbessungsvorschlägen augenscheinlich ungenutzt bleiben. Man könnte 
doch  auf dem "kleinen Dienstweg" ohne FSF- und Atmel-Bürokratie eine 
Liste von ausstehenden nicht-offiziellen Patches (binutils, compiler, 
libc) inkl. Links (evtl. in ein testing-UVZ von Jörgs "BSD-Sammlung") 
und ein paar erklärenden Worten in die avr-libc Dokumentation aufnehmen. 
Das wäre eine recht prominente Stelle und auch für diejenigen gut 
auffindbar, die nicht alle relevanten Mailinglisten, Foren und 
Bugtracker mitverfolgen aber dennoch etwas über den WinAVR Tellerrand 
schauen möchten.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:

> Das war Anfang Januar. Angeblich wollten sie was schicken.
> Als nach über 3 Monaten noch nix angekommen war, hab ich mal vorsichtig
> nachgefragt...keine Antwort. Soviel zu dem Thema.

Dann solltest du mal penetrant werden.  Dummerweise steht und fällt
die Bearbeitungsqualität dieses Jobs wohl mit dem Sekretär/der
Sekretärin, die diesen Kram offenbar in Teilzeit erledigt.  Hab ich
damals wohl Glück gehabt, bei mir lief das sehr reibungslos.

> Ok, wenn das Dummheit von Atmel ist, selber Schuld.

Naja, Rechtsabteilung halt.  Das ist bei einem derartigen VEB wohl
sowas wie ein Staat im Staate. :-(   Die Inschenöre hätten das sicher
lieber heute als morgen im offiziellen Tree drin, es macht sicher
keinen Spaß, den ganzen AVR32-Krams außerhalb zu pflegen.

Außerdem ist natürlich auch irgendwie Sturheit der FSF im Spiel.  Dieses
Bestehen auf der Copyright-Abtretung ist nicht völlig verständlich, das
würde gut auch ohne dem gehen.

Das blöde ist, dass du deinen Patch nicht einfach jemandem anders in
die Hand drücken kannst, damit er das in seinem Namen einarbeitet,
denn die GNU-Leute legen ausdrücklichen Wert darauf, dass die jeweils
vorgebrachten Änderungen auch das geistige Eigentum desjenigen sind,
der sie vorbringt.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin Thomas schrieb:

> Man könnte
> doch  auf dem "kleinen Dienstweg" ohne FSF- und Atmel-Bürokratie eine
> Liste von ausstehenden nicht-offiziellen Patches (binutils, compiler,
> libc) inkl. Links (evtl. in ein testing-UVZ von Jörgs "BSD-Sammlung")
> und ein paar erklärenden Worten in die avr-libc Dokumentation aufnehmen.

Hmm, im Prinzip gibt's ja schon zwei Stellen dafür.  Leider bin ich
selbst in letzter Zeit ziemlich ins Hintertreffen mit den BSD-Patches
gekommen, aber das wäre die erste Stelle.  Die zweite ist das CVS
von WinAVR auf sourceforge.net.

Ja, wenn das mit Johanns FSF-Papierkram partout nicht geht, könnte
man seine Patches auf diesem Wege zumindest überhaupt einem größeren
Publikum zu Gute kommen lassen.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Martin Thomas schrieb:
>
>> Man könnte
>> doch  auf dem "kleinen Dienstweg" ohne FSF- und Atmel-Bürokratie eine
>> Liste von ausstehenden nicht-offiziellen Patches (binutils, compiler,
>> libc) inkl. Links (evtl. in ein testing-UVZ von Jörgs "BSD-Sammlung")
>> und ein paar erklärenden Worten in die avr-libc Dokumentation aufnehmen.
>
> Hmm, im Prinzip gibt's ja schon zwei Stellen dafür.  Leider bin ich
> selbst in letzter Zeit ziemlich ins Hintertreffen mit den BSD-Patches
> gekommen, aber das wäre die erste Stelle.  Die zweite ist das CVS
> von WinAVR auf sourceforge.net.

Eric und Anatoly sind ja fleissig Patches am sammeln.
Das blöde ist, daß man so irgendwann nicht mehr damit arbeiten kann. Man 
kann nicht ein Patch auf einem anderen basieren lassen, es gibt keine 
Weiterentwicklung, und wenn Eric die Patches nicht in die Win-Distri 
einbauen würde, gäb's nicht ein mal nen live-Test und Bugs blieben 
unentdeckt.

Wenn ich heute ein Patch gegen trunk mache, weiß ich, daß sich das mit 
zig anderen Patches in die Wolle bekommen wird...

Und weil es keine Entwicklung auf gcc-Ebene gibt, weiß man nie genau, 
welche Patches wo rumschwirren, sich widersprechen, oder schon 
existieren, so daß man evtl. Arbeit doppelt machen würde. Beispiel 
builtins.

Größere Patches wie die Bit-Optimierungen konflikten mit anderen, und an 
64-Bit Instruktionen oder Tail-Call-Optimierung ist momentan nicht zu 
denken. Nicht aus technischen Gründen, sondern aus organisatorischen.

Johann

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.