Forum: Compiler & IDEs "Optimierung" bei Multiplikation


von Plutimikation (Gast)


Lesenswert?

Ähm.. hallo :-)

Ich bin vorhin auf seltsame "Otpimierungen" beim avr-gcc gestossen.
Warum um alles in der Welt werden Multiplikationen bei 2er-Potenzen mit 
seltsamen add-Schleifen realisiert, anstatt den mul-Befehl zu benutzen ?

Habe ich einen Compiler-Schalter vergessen ?

Es geht um den aktuellen win-avr.

von Michael S. (fandjango)


Lesenswert?

add ist bis zu einer gewissen Grenze bei der Anzahl der Schleifen 
wesentlich schneller als auch ein hardware MUL

von Michael S. (fandjango)


Lesenswert?

oder etwa doch nicht?
dann ist der Kompiler bemüht, hier zu optimieren wo es nicht nötig wäre.
Also ab in die AVR Referenz, sorry...

von Plutimikation (Gast)


Lesenswert?

Ein mul benötigt zwei Takte.

von Plutimikation (Gast)


Lesenswert?

Es wäre wirklich mal Zeit für einen Fork des GCC, der dann auch mit 
8-Bit besser klar kommt.

Was der GCC da teilweise abliefert ist ja grausam.

von Michael S. (fandjango)


Lesenswert?

Habe in der Tat zu dem Thema was gefunden:

Unter: 
http://mekonik.wordpress.com/2009/03/18/arduino-avr-gcc-multiplication/

The way AVR GCC handles multibyte multiplication is caused by writing 
the code in C that doesn’t allow for exact specifications of the operand 
and result sizes and as such it is not a bug, it’s a feature that we 
have to be aware of. But there is a bug in AVR GCC that causes the 
compiler to produce a suboptimal code for multiplications by a constant, 
see forum post at AVR Freaks forum. The problem is that multiplication 
by a power of 2 is interpreted as shifts even when it is worse than 
actual multiplication. Shifts are sometimes worse because AVR offers 
only 1-bit shifts of 8-bit operands. For instance, the simple code
1
int a = -10;
2
int x;
3
4
void setup() {
5
  x = a * 64;
6
}
7
8
gets compiled as
9
10
  ca:  36 e0         ldi  r19, 0x06  ; 6
11
  cc:  88 0f         add  r24, r24
12
  ce:  99 1f         adc  r25, r25
13
  d0:  3a 95         dec  r19
14
  d2:  e1 f7         brne  .-8
15
16
This takes more then 30 cycles, while writing this as a multiplication would take 8. That’s a huge difference.

von Michael S. (fandjango)


Lesenswert?

Der AVR Freaks Forum post zu diesem Thema ist:

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=75909

Das ganze ist wohl schon ein kleiner Hammer.

Bei großen Wortlängen und Power of Two bin ich aber aus frühester 
Kindheit immer noch ein Freund von SHIFT oder ADD. Aber ich hatte 
vergessen wie Leistungsfähig der AVR MUL ist.

von Plutimikation (Gast)


Lesenswert?

..das schlimme ist, am kann den gcc nichtmal mit

a=b*15+b anstelle von a=b*16

vernatzen. Der ist so "schlau" das zusammenzufassen. grrrr.

Gibts einen anderen Trick ?

von Michael S. (fandjango)


Lesenswert?

So wie es ausieht könnte es ein wenig aber nur ein wenig helfen, wenn 
keine der VARs global ist sondern lokal und am besten static. Das ist 
aber ein ziemliches Getue und geht nicht immer.

Der Bug ist unter

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39250

zu sehen und wird wohl gefixt werden. Offen seit FEB 2009? wie es 
ausshieht.

Es wird eben zu hart auf Shift oder ADD gewechselt bei Zweierpotenzen. 
Bei *2 ists ok, aber ab *4 aufwärts total schlecht.

Die Optimierung ist nicht schaltbar und unabhängig vom Target, ob es MUL 
hat oder nicht.

von Plutimikation (Gast)


Lesenswert?

Da es in der Mehrzahl der Fälle nicht so dolle ist, wäre es wohl das 
kleinere Übel, auf diese "optimierung" ganz zu verzichten - da es ja 
scheinbar seit Feb nicht möglich ist, das zu beheben. Da gibt auch viele 
Bugs, die wesentlich älter sind.

Nö.. stattdessen werden immer neue GCC Version 4.x.x übernommen die 
regelmässig für den AVR ungünstiger werden. :-(

Dann lieber einen alten Stand - und den dann nach und nach für 8-Bit 
Targets verbessern.

von Peter D. (peda)


Lesenswert?

Das geht den meisten so, daß man zwar schnell merkt, daß der AVR-GCC auf 
dem falschen Dampfer ist, aber dann kommt sofort die Totschlagkeule: 
"Dann schreib doch nen Patch".

Also bin ich lieber still und akzeptiere es.
Außer beim ATtiny2313 hat ja Atmel den Flash deutlich hochgeschraubt, da 
läßt sichs verschmerzen. Selbst die 8-Pinner haben schon 8kB.

Der AVR-GCC ist sehr störrisch, er merkt fast immer, wenn man ihn in die 
richtige Richtung schubsen will und ignoriert es.
Versuch mal ne Variable abhängig von nem Bit auf 0 oder 1 zu setzen, das 
wird ne riesen 16Bit-Schiebe-Zähl-Maskiere-Orgie, völlig egal, wie Du es 
schreibst.

Extrem unlustig ist er beim Register-Renaming. Der AVR hat ja 32 
Register, aber das interessiert den GCC nicht. Er hat den starken Hang 
unnütz Variablen zwischen Registern umherzuschaufeln. Das gibt 
zusätzlich noch nen Haufen unnötiger PUSH/POPs. Am liebsten schaufelt er 
grundlos auf R18, R19.


Peter

von Plutimikation (Gast)


Lesenswert?

Ja, das mit r18,r19 ist mir schön öfters aufgefallen.

Das mit der Multiplikation will mir aber ganz und garnicht einleuchten.
Ist das nie getestet worden, bevor diese "optimierung" in den avr-gcc 
aufgenommen wurde ?

Oder hat das mal ein einer alten Version funktioniert ?
Wobei,  das wäre nur noch ein Argument mehr, auf diese Versionitis zu 
verzichten, und zu forken.

von Stefan E. (sternst)


Lesenswert?

Peter Dannegger schrieb:

> Versuch mal ne Variable abhängig von nem Bit auf 0 oder 1 zu setzen, das
> wird ne riesen 16Bit-Schiebe-Zähl-Maskiere-Orgie, völlig egal, wie Du es
> schreibst.

1
  var = (PORTB & (1<<PB4)) > 0;
2
  56:  80 e0         ldi  r24, 0x00  ; 0
3
  58:  2c 99         sbic  0x05, 4   ; 5
4
  5a:  81 e0         ldi  r24, 0x01  ; 1
5
  5c:  80 93 00 01   sts  0x0100, r24
6
7
  var = (var & (1<<4)) > 0;
8
  56:  80 91 00 01   lds  r24, 0x0100
9
  5a:  90 e0         ldi  r25, 0x00  ; 0
10
  5c:  84 fd         sbrc  r24, 4
11
  5e:  91 e0         ldi  r25, 0x01  ; 1
12
  60:  90 93 00 01   sts  0x0100, r25

;-)

von Plutimikation (Gast)


Lesenswert?

Selbst wenn er shiften soll, mach er ne "add" schleife draus.

Heißt also, diese in c-Programman sehr beliebte Variante die angeblich 
schneller sein soll, kann man sich auch sparen und einfach 
multiplizieren (damit der compiler dann wieder addiert, eine 
schleifenvariable runterzählt und springt :-()

Ich wage zu behaubten, daß mehr als 90% aller AVR-Programme unter diesem 
Bug "leiden" und eigentlich schneller + kürzer sein könnten. Auf einem 
Tiny kann das sehr weh tun.

von (prx) A. K. (prx)


Lesenswert?

Plutimikation schrieb:

> Ich wage zu behaubten, daß mehr als 90% aller AVR-Programme unter diesem
> Bug "leiden" und eigentlich schneller + kürzer sein könnten. Auf einem
> Tiny kann das sehr weh tun.

Dieser Tiny hat allerdings keinen Multiplier.

von Plutimikation (Gast)


Lesenswert?

Das ändert natürlich alles.

^^

von (prx) A. K. (prx)


Angehängte Dateien:

Lesenswert?

Notfalls muss man eben mit Hilfsfunktionen nachhelfen. Sollte eigentlich 
der Compiler tun, aber zumindest solange Johanns Patches nicht drin sind 
kann man sich so behelfen.

Auf den Tinys geht das natürlich auch nicht.

von Plutimikation (Gast)


Lesenswert?

Mein Dank :-)

von Dirk S. (disc)


Lesenswert?

Hallo,
ein paar mehr Varianten von GCC-Inline-Multiplikationen gibt es auch 
noch bei

Beitrag "GCC Inline Assembler Multiplikationen"

Gruß

Dirk

von Peter D. (peda)


Lesenswert?

Stefan Ernst schrieb:
>
1
  var = (PORTB & (1<<PB4)) > 0;
2
>   56:  80 e0         ldi  r24, 0x00  ; 0
3
>   58:  2c 99         sbic  0x05, 4   ; 5
4
>   5a:  81 e0         ldi  r24, 0x01  ; 1
5
>   5c:  80 93 00 01   sts  0x0100, r24
6
>

Genau das ist es, was mich ärgert.
Der Compiler weiß, wie es richtig geht, aber macht es absichtlich 
aufwendig.

Man braucht also ein extra Wörterbuch, wo alle Ausdrücke drinstehen, 
welche dem Compiler gefallen.

Warum kann er den Code nicht genau so compilieren, wie ich ihn 
hinschreibe?


Peter

von (prx) A. K. (prx)


Lesenswert?

Peter Dannegger schrieb:

> Warum kann er den Code nicht genau so compilieren, wie ich ihn
> hinschreibe?

Weil man so im Workstation- und High-Performance-Bereich keinen 
Blumentopf gewinnt. Diese Optimierungen finden im maschinenunabhängigen 
Teil statt und manchmal vergessen die Leute, dafür Schalter vorzusehen, 
die man beim AVR dann nutzen könnte.

von yalu (Gast)


Lesenswert?

Ich glaube, der GCC braucht etwas Verteidigung :)

> void setup() {
>   x = a * 64;
> }
>
> gets compiled as
>
>   ca:  36 e0         ldi  r19, 0x06  ; 6
>   cc:  88 0f         add  r24, r24
>   ce:  99 1f         adc  r25, r25
>   d0:  3a 95         dec  r19
>   d2:  e1 f7         brne  .-8
>
> This takes more then 30 cycles, while writing this as a multiplication
> would take 8. That’s a huge difference.

Bei diesem Test wurde wohl mit -Os optimiert. -Os optimiert die Codegrö-
ße, und der erzeugte Code ist tatsächlich kürzer als bei der Verwendung
von MUL-Befehlen, also gibt es daran überhaupt nichts zu meckern.

Will man Geschwindigkeit, optimiert man mit -O2. Dann werden statt der
30 nur 9 Zyklen benötigt, was schon dicht am Optimum (8) liegt. Da der
GCC keine 8x16->16-Multiplikation erzeugen kann¹, und selbst bei der
16x16->16-Multiplikation noch ein paar überflüssige Befehle einfügt¹,
liegt die kürzestmögliche Multiplikation mit MUL-Befehlen bei 13 Zyklen,
so dass es an den 9 Zyklen wirklich nichts auszusetzen gibt.

Es gibt allerdings einige Faktoren (z.B. 29), wo der Compiler die Shift-
Methode wählt, obwohl sie mit 16 Zyklen noch länger als die schlecht op-
timierte MUL-Methode (13 Zyklen) dauert¹.

Wenn man bedenkt, dass für eine Konstantenmultiplikation gegenüber dem
Optimum maximal 8 Zyklen verschenkt werden, und ein Programm nur in ganz
seltenen Fällen zu mehr als 5% aus Multiplikationen besteht, ist dies in
meinen Augen trotzdem kein Thema für lautes Gemecker oder gar einen Bug-
Report.

Ich habe im Folgenden die Dauer der Multiplikation eines 16-Bit-Integers
mit ausgewählten Konstanten zusammengestellt:

Testprogramm:
1
volatile int a, b;
2
void sub(void) {
3
  b = a * 64;
4
}

Ergebnisse:

Gezählt habe ich die Zyklen ohne die LDS- und STS-Befehle zum Laden und
Speichern der Volatile-Variablen. Der Controllertyp ist der ATmega8, die
Optimierungsstufe -O2, die GCC-Version 4.4.1.
1
Faktor   Zyklen
2
    1      0   \
3
    2      2    |
4
    4      4    |
5
    8      6    |
6
   16      6    |
7
   32      8    |
8
   64      9    |
9
  128      5    |
10
  256      2    |
11
  512      3    |
12
 1024      4    |
13
 2048      5     > mit shift/swap
14
 4096      4    |
15
 8192      5    |
16
16384      8    |
17
    3      5    |
18
    5      7    |
19
    7      9    |
20
    9      9    |
21
   15     12    |
22
   17      9    |
23
   19     14    |
24
   29     16   /
25
   31     13      mit mul

Ich finde den AVR-GCC trotz seiner Schwächen so gut, dass ich weder für
private noch für kommerzielle Projekte in einen IAR-Compiler investieren
würde.

Übrigens lohnt es sich, hin und wieder eine aktuelle Version des AVR-GCC
anzuschauen. Nachdem der AVR-GCC in der Version 4.3.x schwere Zeiten
durchlaufen hat und jeder, der keinen neuen Controllertyp einsetzte,
lieber zum 4.2.4 zurückgekehrt ist, sind in 4.4.x einige Verbesserungen
hinzugekommen, die sich auch im erzeugten AVR-Code positiv bemerkbar
machen (sowohl in Bytes als auch Zyklen). Auch wenn der Gesamteindruck
noch durch das 4.3.x-Erbe geprägt ist, scheint es AVR-mäßig endlich
wieder etwas voranzugehenn. Das ist zumindest mein subjektiver Eindruck.


¹) An diesen Stellen gibt es vielleicht Grund für leise Kritik.

von Peter D. (peda)


Lesenswert?

A. K. schrieb:
> Weil man so im Workstation- und High-Performance-Bereich keinen
> Blumentopf gewinnt. Diese Optimierungen finden im maschinenunabhängigen
> Teil statt und manchmal vergessen die Leute, dafür Schalter vorzusehen,
> die man beim AVR dann nutzen könnte.

Mal ne rein theoeretische Frage (patchen ist ja für einen Benutzer 
praktisch unmöglich), wo würde dann ein Patch ansetzen?

Würde er schon die Deoptimierung abbrechen oder würde er sie erst im 
maschinenabhängigen Teil erkennen und rückgängig machen?


Peter

von Peter D. (peda)


Lesenswert?

yalu schrieb:
> Übrigens lohnt es sich, hin und wieder eine aktuelle Version des AVR-GCC
> anzuschauen.

Mache ich doch.
Aber der aktuelle WINAVR ist leider erst 4.3.2, da muß man sich wohl 
noch in Geduld üben.


Peter

von (prx) A. K. (prx)


Lesenswert?

Peter Dannegger schrieb:

> Mal ne rein theoeretische Frage (patchen ist ja für einen Benutzer
> praktisch unmöglich), wo würde dann ein Patch ansetzen?

Spezialist hierfür ist Johann L. Wir hatte hier schon einmal einen 
Thread zu genau diesem Thema.

Patchen ist etwas einfacher, wenn man Zielplattformen verwendet, die 
sich aus dem offiziellen Sourcecode von GCC heraus ohne einen 
Rattenschwanz an Sonderpatches verwenden lassen (die bei AVR oft 
anfallen, nicht zuletzt weil sich diese Zielplattform schlecht live 
testen lässt). Und man mit Linux arbeitet.

Da ich im Compiler nicht so tief drinstecke würde ich einen Code-Teil, 
der für zweifelhafte "Optimierung sorgt", schlicht um einen Schalter 
(wie -flassmichinruhe) bereichern.

Eine bessere Lösung für manche dieser Optimierungsprobleme würde wohl 
versuchen, die evtl. mitunter falsche Einschätzung zur Komplexität von 
Operationen zu korrigieren.

Für die 16x8-Multiplikationen hat Johann bereits einen Patch gebaut, der 
das entsprechende Template hinzufügt. Damals möglicherweise nur 
unsigned, aber das gleichePrinzip funktioniert ja auch signed.

von (prx) A. K. (prx)


Lesenswert?

Peter Dannegger schrieb:

> Aber der aktuelle WINAVR ist leider erst 4.3.2, da muß man sich wohl
> noch in Geduld üben.

Wie du ja weisst ist das nicht immer nur ein Vorteil. So hat(te?) die 
4.4-er bei ARMs die hässliche Angewohnheit, an den hirnrissigsten völlig 
überflüssige Stellen Sign/Zeroextensions durchzuführen.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Plutimikation schrieb:

> Es wäre wirklich mal Zeit für einen Fork des GCC, der dann auch mit
> 8-Bit besser klar kommt.

Mach doch.

Wenn du dich wirklich so gut im GCC auskennst, wie du hier tust, warum
gehörst du dann nicht schon längst zu denjenigen, die sich solcher
Probleme einfach mal annehmen statt hier große Bögen zu spucken?  Man
könnte einen großen Teil der existierenden Probleme wohl ganz sicher
bereits in der jetzigen Codebasis lösen, wenn, ja wenn nur, die
benötigte man power überhaupt erst einmal da wäre.

Aber ohne man power wird auch dein beschworener Fork ein reiner
Papiertiger bleiben, den kein Schwanz benutzen will.  Seltsamerweise
werfen Leute mit vernünftigen Namen und erwiesenem Durchblick im
GCC-Code sehr selten mit solchen Parolen um sich.  Dafür sieht man von
denen auch mal Code, der was repariert.

Das Ganze hat übrigens mit GCCs nicht gerade vorhandener Vorliebe für
8-Bitter ausnahmsweise mal recht wenig zu tun, im Gegenteil: eine
derartige Optimierung braucht man gerade bei kleinen Prozessoren
ohne Hardware-Multiplikation, also auch und gerade bei einem Teil der
AVRs (ATtiny).

von Plutimikation (Gast)


Lesenswert?

Ganz im Gegenteil, man benötigt sogar weniger man-power, ganz einfach 
weil man nicht damit beschäftigt ist Regressions der ständig wechselnden 
GCC-Versionen zu reparieren und die gesparte Zeit dazu nutzen kann den 
AVR-Teil weiterzuentwickeln.

Ich benutze immer noch oft einen uralt avr-gcc, da der oft! immernoch 
kürzen code erzeugt als heutige Versionen. Was soll also die 
GCC-Versionitits ? Hat die für "unser" Target irgendeinen Vorteil ?
Würde man einen alten nehmen und diesen weiterentwickeln (=erstmal auf 8 
Bit optimieren), wäre im Endeffekt Zeit und Manpower gespart.

Aber die Zeit der 8-Bitter neigt sich sowieso langsam dem Ende, darum 
ist es inzwischen wohl fast egal.

Also kein Grund, sich aufzuregen.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Plutimikation schrieb:
> Ganz im Gegenteil, man benötigt sogar weniger man-power, ...

Wir warten immer noch auf deinen Beitrag.  Nicht in Form von Worten,
sondern in Form von Code.  Alles andere hilft keinem weiter.

von Plutimikation (Gast)


Lesenswert?

Aha, das übliche "Totschlagargument". Andere scheint es ja nicht zu 
geben :-)

von (prx) A. K. (prx)


Lesenswert?

Plutimikation schrieb:

> Aha, das übliche "Totschlagargument". Andere scheint es ja nicht zu
> geben :-)

Dein Argument "investiert gefälligst mehr von eurer unbezahlten Zeit 
damit ich ein kostenloses Produkt besser nutzen kann" ist besser?

Open Source heisst, dass man entweder selber Hand anlegt, oder mit dem 
lebt was andere zur Verfügung stellen. Drüber meckern aber nicht 
konstruktiv beitragen entspricht nicht dem Business-Modell solcher 
Software. Dafür gibt es kommenzielle Entwicklungssysteme.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Plutimikation schrieb:
> Aha, das übliche "Totschlagargument". Andere scheint es ja nicht zu
> geben :-)

Klar.  Du theoretisiert über Dinge, von denen du offensichtlich
keinen Schimmer hast und stellst irgendwelche Behauptungen auf, die
du nicht einmal ansatzweise beweisen kannst.  Einen Namen willst du
uns auch nicht verraten.  Wie soll man dich da irgendwie ernst
nehmen?

von Plutimikation (Gast)


Lesenswert?

Wo auch immer du das herausliest, es ist falsch. Ich schrieb doch klipp 
und klar, daß ich der Ansicht bin, daß man sogar weniger Zeit braucht ?

Aber das führt zu nix, ich schlage EOD vor.

- Unabhängig davon ist Eure Arbeit daran nämlich Klasse. Ich finde es 
einfach nur schade um die vertane Zeit die mit GCC-Versions-hecheln 
verbracht wird.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Plutimikation schrieb:
> Wo auch immer du das herausliest, es ist falsch. Ich schrieb doch klipp
> und klar, daß ich der Ansicht bin, daß man sogar weniger Zeit braucht ?

Das schriebst du, und genauso begründungslos schreibe ich dir, dass
ich diese Ansicht für Quatsch halte.  Wir (die AVR-Gemeinde) profi-
tieren an vielen Stellen von der generischen Arbeit des GCC, um unseren
eigenen Kram müssten wir uns halt nur selbst kümmern.  Solange es aber
nur 1,5 aktive AVR-GCC-Entwickler gibt, werden da keine großen Sprünge
passieren.  Da wird auch dein Fork nicht helfen.

von Läubi .. (laeubi) Benutzerseite


Lesenswert?

Hm... könnte man den wenn man wollte beim AVR-GCC überhaupt 
"mitentwickeln"? Ich stelle mir das nicht so einfach vor da mal eben 
einzusteigen...

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Läubi .. schrieb:
> Hm... könnte man den wenn man wollte beim AVR-GCC überhaupt
> "mitentwickeln"?

Im Prinzip schon.  Allerdings benötigt man dazu ein brauchbares
Verständnis der internen Abläufe im GCC.  Ich habe zwei-, dreimal
Anlauf genommen, aber das ist leider nicht mein Ding.

Am Ende kocht aber jeder nur mit Wasser, und keinem ist in die
Wiege gelegt worden, mal GCC-Code schreiben zu können. ;-)  Denis
Chertykov hat sich seinerzeit eben auch einfach mal hingesetzt und
überhaupt eine Portierung gemacht, und Anatolij Sokolov als derzeit
wesentlicher AVR-GCC-Maintainer ist in diese Rolle auch nur dadurch
gelangt, dass er gezeigt hat, dass er einerseits die Materie versteht
und andererseits gewillt ist, aktiv daran zu arbeiten.  (Eine formale
Voraussetzung gibt's noch, man muss der FSF eine Copyright-Abtritts-
Erklärung unterschreiben.  Ist ein Papiertiger, insbesondere da man
als Deutscher ein Copyright gar nicht abtreten kann...)

von Läubi .. (laeubi) Benutzerseite


Lesenswert?

Jörg Wunsch schrieb:
> gelangt, dass er gezeigt hat, dass er einerseits die Materie versteht
> und andererseits gewillt ist, aktiv daran zu arbeiten.  (Eine formale
> Voraussetzung gibt's noch, man muss der FSF eine Copyright-Abtritts-
> Erklärung unterschreiben.  Ist ein Papiertiger, insbesondere da man
> als Deutscher ein Copyright gar nicht abtreten kann...)
Das heißt ich muß denen ein Papier unterschreiben bevor man mitarbeiten 
darf? Das ist natürlich eher... unattraktiv.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Läubi .. schrieb:

> Das heißt ich muß denen ein Papier unterschreiben bevor man mitarbeiten
> darf? Das ist natürlich eher... unattraktiv.

Naja, es ist nicht tragisch, sofern sich die FSF zumindest einigermaßen
beeilt.  Leider haben sie offenbar nur eine Teilzeit-Sekretöse dafür,
und ich weiß von Johann Lay, dass er seinerzeit mächtig gewartet hat,
bis von denen endlich eine Bestätigung kam (wenn's überhaupt schon
geschafft ist).  Ich habe das Ganze vor Jahren mal für GCC, Binutils
und GDB auf einmal eingereicht, und es ging vergleichsweise zügig (alles
in allem zwei Monate oder so).  Dadurch haben wir ja nun zumindest die
0b-Konstanten ganz offiziell im GCC drin. ;-)

von Hc Z. (mizch)


Lesenswert?

Läubi .. schrieb:

> Das heißt ich muß denen ein Papier unterschreiben bevor man mitarbeiten
> darf? Das ist natürlich eher... unattraktiv.

Es handelt sich um eine Absicherung der FSF, weil übers Urheberrecht 
viel schmutzige Wäsche gewaschen wird und man verhindern will, dass ein 
Wettbewerber über diesen Hebel ganze Projekte lahmlegen kann.

Die Abwicklung ist nicht immer reibungslos (eines meiner Assignments 
verschwand im Nirvana), aber eine wirkliche Hürde ist es auch nicht, 
wenn man an einer Mitarbeit interessiert ist und (was immer der Fall 
sein sollte) wirklich nur eigenen Code weitergibt, an dem Dritte keine 
Rechte haben.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Hazeh Zimmerer schrieb:

> Es handelt sich um eine Absicherung der FSF, weil übers Urheberrecht
> viel schmutzige Wäsche gewaschen wird und man verhindern will, dass ein
> Wettbewerber über diesen Hebel ganze Projekte lahmlegen kann.

Ihre offizielle Begründung ist, dass sie nur so in der Lage wären,
beispielsweise bei GPL-Verletzungen selbst rechtliche Schritte
einleiten zu können.  Klingt mir ein wenig an den Haaren herbei
gezogen.

von Hc Z. (mizch)


Lesenswert?

Mir auch.  Die FSF kann sich halt nicht leisten, dass sie fremde Rechte 
verletzt, wo sie doch in dem Minenfeld von Urheberrechten und 
Softwarepatenten ganz vorne tätig ist.  Dass sie sich da absichert, ist 
verständlich.  (Mancher Werk- oder Arbeitsvertrag dürfte ja tatsächlich 
mit dem Assignment kollidieren, einer meiner früheren hätte es 
jedenfalls.)

von yalu (Gast)


Lesenswert?

Leicht OT, aber passend zum Thema "Fortschritt oder Rückschritt beim
AVR-GCC":

Die C Funktion:
1
char swap(char b) {
2
  return b<<4 & 0xf0 | b>>4 & 0x0f;
3
}

Übersetzt vom 4.2.4:
1
swap:
2
  mov r25,r24
3
  swap r25
4
  andi r25,0x0f
5
  swap r24
6
  andi r24,0xf0
7
  or r25,r24
8
  mov r24,r25
9
  clr r25
10
  sbrc r24,7
11
  com r25
12
  ret

Übersetzt vom 4.3.4:
1
swap:
2
  mov r25,r24
3
  swap r24
4
  andi r24,0xf0
5
  swap r25
6
  andi r25,0x0f
7
  or r24,r25
8
  ret

Übersetzt vom 4.4.2:
1
swap:
2
  swap r24
3
  ret

Da soll noch einer behaupten, die GCC-Entwickler würden den AVR-Teil
links liegen lassen!

von Lars R. (larsr)


Lesenswert?

Hallo,

Ich hätte bei dieser Gelegenheit mal eine ganz einfache Frage, aber 
lacht mich bitte nicht aus...

Wo bekommt man eine aktuelle AVR-GCC-Version her?

Meine Suchen resultierten nur in Verweisen zu Seiten von Anwendern oder 
wie hier zu einem Wiki-Artikel der nur beschreit, was AVR-GCC kann, aber 
nicht, wo man ihn bekommt. Oder ich habe den Link im Wiki übersehen...

Momentan verwende ich die WinAVR-Version von SF. Aber die ist ja 
bestimmt nicht mehr aktuell.

Viele Grüße,

Lars

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Lars R. schrieb:

> Momentan verwende ich die WinAVR-Version von SF. Aber die ist ja
> bestimmt nicht mehr aktuell.

Wenn du etwas aktuelleres haben willst, musst du auf die nächste
WinAVR-Version warten oder halt selbst bauen.  Letzteres wird yalu
ganz sicher gemacht haben, um bspw. die GCC-Version 4.4.2 zu testen.

von Lars R. (larsr)


Lesenswert?

Hallo Jörg,

Danke für deine Antwort.

> Wenn du etwas aktuelleres haben willst, musst du auf die nächste
> WinAVR-Version warten oder halt selbst bauen.  Letzteres wird yalu
> ganz sicher gemacht haben, um bspw. die GCC-Version 4.4.2 zu testen.

Ich würde dies ja auch gerne versuchen, doch wie komme ich an die 
Quelltexte des AVR-GCC?

Gibt es irgendwo eine Website zum Projekt, wo entsprechende Infos zu 
bekommen sind?

Viele Grüße,

Lars

von Mark B. (markbrandis)


Lesenswert?

Jörg Wunsch schrieb:
> Wenn du etwas aktuelleres haben willst, musst du auf die nächste
> WinAVR-Version warten oder halt selbst bauen.  Letzteres wird yalu
> ganz sicher gemacht haben, um bspw. die GCC-Version 4.4.2 zu testen.

Es würde ja reichen wenn einmal jemand die kompilierten Binaries online 
stellen würde für x86, muss doch nicht jeder selbst von neuem den Build 
machen?

von yalu (Gast)


Lesenswert?

Mark Brandis schrieb:
> Jörg Wunsch schrieb:
>> Wenn du etwas aktuelleres haben willst, musst du auf die nächste
>> WinAVR-Version warten oder halt selbst bauen.  Letzteres wird yalu
>> ganz sicher gemacht haben, um bspw. die GCC-Version 4.4.2 zu testen.
>
> Es würde ja reichen wenn einmal jemand die kompilierten Binaries
> online stellen würde für x86, muss doch nicht jeder selbst von neuem
> den Build machen?

Ich habe den AVR-GCC in jeweils in der neuesten 4.2.x- 4.3.x- und 4.4.x-
Version als Arch-Linux-Paket gebaut und installiert. Da die meisten hier
Windows verwenden, nützt ihnen das natürlich nicht viel. Falls jemand an
den Arch-Linux-Paketen interessiert ist, kann ich diese aber gerne zur
Verfügung stellen. Die Builds enthalten allerdings keine Patches und
sind von mir (bis auf die 4.2.4-Version) nur wenig getestet worden, so
dass sie nicht unbedingt für den produktiven Einsatz geeignet sind.

Für den Arch-User ist es aber auch kein Problem, das Paket selbst zu
erstellen: Einfach die Paketbeschreibungsdatei von hier

  http://repos.archlinux.org/wsvn/community/gcc-avr/repos/community-i686/

herunterladen, im Editor die Versionsnummer von 4.4.1 in 4.4.2 ändern
und makepkg aufrufen. Damit werden in einem Rutsch die GCC-Sourcen
heruntergeladen, die Sourcen für AVR konfiguriert, das Ganze kompiliert
und die Binaries zu einem Paket geschnürt.

Es gibt aber sicher den einen oder anderen, der das auch für Windows ge-
macht hat. Es gab auch schon Anleitungen dazu im Netz, wobei das Selber-
bauen unter Windows etwas aufwendiger ist, weil man erst einmal die x86-
Entwicklungstools installieren muss. MinGW dürfte aber reichen, und das
ist wiederum ein All-Inclusive-Paket, wo man bei der Installation nicht
so viel nachdenken muss.

Bitte 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
Noch kein Account? Hier anmelden.