mikrocontroller.net

Forum: Compiler & IDEs Warum verwendet WinAVR nie swap/mul ?


Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe ein LCD an einen mega8 angeschlossen.
Die 8bit Daten zum LCD sind an PortB angeschlossen. Da ich den UART
brauche, habe ich D0-1 an PortB4 und PortB5 angeschlossen.
Gebe ich jetzt die 8 bit Daten aus, würde ich in Assembler
warscheinlich einfach swap verwenden, um die Bits 0&1 auf Stelle 4&5 zu
bekommen, oder was auch gehen würde, wäre mul.
Wiso macht WinAVR das ganze aber mit Shifts ? Das dauert mindestens 5x
solange... Kann man WinAVR irgendwie dazu bringen swap zu verwenden ?

    PORTD=byte;
    PORTB=byte*16;

 2463 0180 C2BB          out 50-0x20,r28
 2464                 .LM104:
 2465 0182 8C2F          mov r24,r28
 2466 0184 9927          clr r25
 2467 0186 34E0          ldi r19,4
 2468 0188 880F        1:  lsl r24
 2469 018a 991F          rol r25
 2470 018c 3A95          dec r19
 2471 018e E1F7          brne 1b
 2472 0190 88BB          out 56-0x20,r24

Autor: Daniel Braun (khani)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

die einfachste Methode, den Compiler genau das machen zu lassen, was
man will, ist inline assembly. Dann passiert genau das was Du schreibst
- wenn man weiß was man will und was man tut ist das eine gute Sache.

In Deinem Fall wäre es auch eine Möglichkeit, dem Herrn Compiler
genauer zu erklären, welche Bits Du überhaupt auf dem Port sehen
willst.

a la : PORTD |= (byte & 0x03) << 4;

Schau doch einfach ma, was er dann macht - vielleicht ja das Richtige
;-)

MfG, Daniel.

Autor: Peter Dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, das ist so.

Der AVR-GCC hat eine extreme 16Bit-Lastigkeit.

D.h. er macht viele 8Bit-Rechnungen erstmal in 16Bit um dann das
High-Byte wieder wegzuschmeißen.

Besonders unangenehm fällt das bei switch-Anweisungen und beim Test auf
Bit 0 auf (Bit 1..7 werden optimal mit SBRS getestet).

Solange das keinen der Leute nervt, die Compiler bauen können, ist da
auch keine Abhilfe in Sicht.

Was mich auch wundert ist, daß bei jeder neuen WINAVR-Version der
erzeugte Code immer größer wird.
Scheint also so, daß Codeoptimierungen kein Bestandteil neuerer
Versionen sind, sondern nur Bug-Fixes (falscher Code) und dabei manche
Optimierungen wieder wegfallen.


Peter

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

Bewertung
0 lesenswert
nicht lesenswert
> Solange das keinen der Leute nervt, die Compiler bauen können, ist
> da auch keine Abhilfe in Sicht.

Nun, wie bei allem: man kan alles lernen.  Auch GCC scheint nicht so
schwer zu lernen zu sein, einige Leute haben das bewiesen.  Sonst gäbe
es keinen AVR-GCC überhaupt (der ist ja nicht irgendwie ,,von den
GCC-Leuten'' gemacht worden, sondern von jemandem, der gern einen
GCC
auf AVR haben wollte).

Wer die einschlägigen Mailinglisten mal verfolgt (die meisten
ernsthaften Entwickler meiden Webforen, wo's nur geht, weil sie im
Vergleich zu Mailinglisten oder Newsgruppen eigentlich nur Nachteile
haben), kann man z. B. sehen, dass Björn Haase gerade einiges gemacht
hat.

> Was mich auch wundert ist, daß bei jeder neuen WINAVR-Version der
> erzeugte Code immer größer wird.

Was mich wundert ist, dass Peters Aussagen immer unsinniger werden.

Merkst du, dass Pauschalisierungen hinken?

Dmitry Xmelov (sp?) hat mal ein paar Analysen veröffentlicht, welcher
Code mit welchen Compilerversionen und -optionen besser oder
schlechter optimiert worden ist.  Es gibt eine gewisse Tendenz, dass
bei AVR tatsächlich die Optimierung nachgelassen hat (was im Sinne von
GCC durchaus als `regression' gilt und damit mehr Priorität beim
Bugfixing geniest als feature fixes -- so man die Bugs denn auch
berichtet), aber es gibt durchaus auch Dinge, die mit neuen Versionen
besser geworden sind.

> Scheint also so, daß Codeoptimierungen kein Bestandteil neuerer
> Versionen sind, sondern nur Bug-Fixes (falscher Code) und dabei
> manche Optimierungen wieder wegfallen.

Korrekter Code wäre natürlich ohnehin wichtiger als gut optmierter
Code.

Anyway, mein persönlicher Eindruck: die 3.4er Versionen vom GCC sind
vor allem so schnell rausgefeuert worden, weil die AMD64-Plattform
(alias x86_64) massiv Priorität genossen hat.  Die war wohl bei 3.3
noch total buggy, aber der Compiler wurde dringlichst benötigt, da die
Prozessoren nun einmal in Massen da sind und auch benutzt werden
möchten.  Offenbar sind bei diesen Hobeleien zuweilen Späne gefallen,
und (eher unbeabsichtigt) andere Targets als die mainstream i386 und
amd64 in die Rubrik ,,Pessimierung'' reingerutscht.  Krassestes
Beispiel war, dass ein bestimmtes Stück Code mit dem C++-Compiler
drastisch schlechter compiliert worden ist als mit dem C-Compiler.
Gleicher Quellcode unter einem GCC 3.3.x ergab (nahezu) identischen
Assemblercode für beide Compiler.

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Je mehr ich mit WinAVR programmiere, desto häufiger überlege ich, ob ich
wirklich ein AVR brauche oder ob das ganze nicht auch in Assembler auf
einem 8051 läuft...

@Daniel
Der Tip war genau richtig ! Deine Lösung wird zu

 2438 016e C2BB          out 50-0x20,r28
 2439                 .LM101:
 2440 0170 C370          andi r28,lo8(3)
 2441 0172 C295          swap r28
 2442 0174 C07F          andi r28,0xf0
 2443 0176 C8BB          out 56-0x20,r28
 2444                 .LM102:

Es ist echt unglaublich, was ein oftmals komplizierterer Code an
Vereinfachung bringen kann.
Wobei der Compiler trotzdem verdammt dumm ist:
Wenn er vor dem swap bits 4-7 löscht, dann bräuchte er hinterher nicht
nochmal bits 0-3 zu löschen...

Autor: Peter Dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter:

> Was mich auch wundert ist, daß bei jeder neuen WINAVR-Version der
> erzeugte Code immer größer wird.

Jörg:

> Es gibt eine gewisse Tendenz, dass
> bei AVR tatsächlich die Optimierung nachgelassen hat


Sorry, aber für mich ist beides das gleiche, nur mit anderen Worten.

Als Optimierung nehme ich immer -Os


Wenn ich das andere richtig verstehe, ich kann also ruhig noch die alte
Version nehmen, wenn ich kein 64Bit-OS benutze ?


Peter

Autor: Peter Dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
P.S.:

Die Unterschiede sind natürlich nur gering (1,5%):


C:\AVR\WINAVR\BIN>avr-gcc.exe -dumpversion
3.3.2

D:\WORK\AVR_C\PU\5KV>a.bat
   text    data     bss     dec     hex filename
   3226      20     351    3597     e0d test.out

C:\AVR\WINAVR\BIN>avr-gcc.exe -dumpversion
3.4.3

D:\WORK\AVR_C\PU\5KV>a.bat
I2C.C:49: warning: `i2c_interrupt' appears to be a misspelled signal
handler
   text    data     bss     dec     hex filename
   3278      20     351    3649     e41 test.out


Peter

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

Bewertung
0 lesenswert
nicht lesenswert
> Wenn ich das andere richtig verstehe, ich kann also ruhig noch die
> alte Version nehmen, wenn ich kein 64Bit-OS benutze ?

Das verstehe ich nun überhaupt nicht.

Du kannst natürlich alte Versionen benutzen, aber du riskierst dann
eben auch, dass du erstens Bugs erliegst, die mittlerweile schon
repariert sind, und zweitens kann es gut auch sein, dass du (je nach
Anwendungsfall) mal die eine oder andere verbesserte Optimierung
verpasst.

Andererseits: das letzte Stück herumfeilen muss man ja eigentlich nur
dann, wenn der gerade genutzte Prozessor kurz vor voll ist oder man
dadurch in der Produktion den nächstkleineren benutzen könnte.  ,,Nur
so aus Sport'' wüsste ich besseres, um mir meine Zeit zu vertreiben.
;-)

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

Bewertung
0 lesenswert
nicht lesenswert
> Je mehr ich mit WinAVR programmiere, desto häufiger überlege ich, ob
> ich wirklich ein AVR brauche oder ob das ganze nicht auch in
> Assembler auf einem 8051 läuft...

Die Frage ist halt die Effizienz der Codeentwicklung.

Für paar wenige Zeilen ist das sicher egal, aber mit zunehmender Größe
des Projekts hast du mit dem Assemblerklumpen eben immer mehr
Wartungsaufwand.  Das kann bei einem größeren Projekt gut auf das
10fache anwachsen.

Autor: Helmut (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach, da hilft doch nur eins: sich nen vernünftigen Compiler aussuchen
und nicht so ein freies Produkt, wo jeder mal irgendwie dran rumwerkelt
und zum Schluß doch nichts sinnvolles bei rumkommt. Eben so, wie auch
bei Linux und Konsorten. Ist doch alles nur eine rießen Baustelle ohne
richtigen Nutzen :) LOL

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

Bewertung
0 lesenswert
nicht lesenswert
> Ach, da hilft doch nur eins: sich nen vernünftigen Compiler
> aussuchen und nicht so ein freies Produkt, wo jeder mal irgendwie
> dran rumwerkelt und zum Schluß doch nichts sinnvolles bei rumkommt.

Klar.  Was soll der Geiz, scheiß auf's neue Auto, lieber für dasselbe
Geld einen IAR EW gekauft. :-)

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich nutze derzeit sowohl linux als auch windows.. und muss zugeben
teilweise sind die linux-tools etwas gewöhnungsbedürftig doch bieten
sie teilweise features die du bei kommerziellen teilen vermissen wirst
wenn du sie gewohnt bist ;)

aja es gibt derzeit nur einen compiler (meines wissens) der auf der
intel plattform schnelleren/kleineren oder wie auch immmer "besseren"
code macht wie der gcc.. das wäre der intel eigene...

und zum thema baustelle.. unter linux gibts nur neue stable-kernels
wenn die auch wirklich stable sind... ausnahme war 2.2 ... wobei
ausrutscher passieren nunmal... siehe win98 ROFL ;)

wenn du jetzt meinst 98 war eine ausnahme..warum gibts von xp ein sp,
dass im prinzip alles wirklich wichtige umdreht??? oder ein 98, das
komplett "neu" war???

ähnliches gibts auch bei 2003.. nur bei 2k ist mir nix bekannt...

anmerken möchte ich noch, dass im prinzip jedes betriebsystem eine
baustelle darstellt.... eigentlich jede anwendung sogar.. es gäbe immer
was zu fixen,...

soo jetzt noch schnell was zum topic G

 wie weit ist der c++ compiler für den avr eigentlich schon optimiert
bzw wie weit reicht der support dafür??? ;) ich steh einfach auf oop..
und bei 128k flash und 64k ram geht das doch ohne probs ;)

73

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

@Helmut
Wer hat dich eigentlich aus dem Heiseforum rausgelassen? Oder bist du
sogar aus dag° entwischt?

SCNR

Matthias

Autor: Helmut (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Klar.  Was soll der Geiz, scheiß auf's neue Auto, lieber für
> dasselbe Geld einen IAR EW gekauft. :-)

Naja, wollen wir mal nicht übertreiben. Der ICCAVR von Imagecraft
kostet 780 Dollar und der ist sein Geld wert. Zwar ist er auch nicht
perfekt, dennoch erzeugt er kleinen und schnellen Code und er ist
schnell durchschaubar (keine ewig langen Textdateien), da z. B.
Einstellungen für Bootloaderapplikationen bequem per Menu erfolgen. Und
man hat eine überschaubare Installation und nicht tausende (?) Dateien
nur für ein Compiler. Es gibt auch keine Probleme, die durch Updates
entstehen. Halt einfach ein gut durchdachtes Produkt. Und wem die
integrierte IDE zu grauenvoll ist, kann jederzeit fürs editieren
edit.com (oder Emacs; pfui bah!) benutzen und in der Console die
Kommandozeilentools des Compilers.

Aber jedem das seine :)

Übrigens bin ich nicht Mitarbeiter von Imagecraft. Dies nur für den
Fall, daß mir Schleichwerbung vorgeworfen wird, was hier im Forum ja
schon öfter mal vorkommt.

Autor: Helmut (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Matthias

> Wer hat dich eigentlich aus dem Heiseforum rausgelassen?
> Oder bist du sogar aus dag° entwischt?

Hehe, du scheinst da ja Stammgast zu sein.

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

Bewertung
0 lesenswert
nicht lesenswert
Nu ja, ganz davon abgesehen, dass mir ein Windowscompiler einfach
mal überhaupt nüscht nützt, hast du mal für mehr als "Hello world"-
Projekte die Codegrößenvergleiche gesehen?

Ganz ernsthaft, für den GCC sehe ich lediglich den IAR als
Alternative (der kostet aber wirklich so viel wie'n gebrauchtes
Auto, und ohne Windows kann ich ihn trotzdem nicht nehmen).

Autor: Helmut (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Nu ja, ganz davon abgesehen, dass mir ein Windowscompiler
> einfach mal überhaupt nüscht nützt

Ok, ICC ist natürlich wirklich nur für Windowsnutzer tauglich :)

Die Codegrößenvergleiche habe ich in der Tat gesehen weil ich mir
selbst mal die Mühe gemacht habe, ein ICCAVR-Projekt auf GCC zu
portieren. Es handelte sich um eine GPS-Anwendung mit aufwendiger
Menüsteuerung (grafisches Display). ICC erzeugte 61kByte Code mit
Optimierung, der GCC machte daraus 79kByte mit Optimierung. Ich hab die
Sache dann in die Tonne getreten, denn hätte ich GCC weiter benutzt, so
wäre ein größerer (und damit teuerer) Controller erforderlich gewesen.

Autor: Patrick Dohmen (oldbug) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
18kByte Differenz?
Also das halte ich für übertrieben...

Autor: Helmut (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich fands auch sehr extrem, bin dem Problem aber auch nicht näher
nachgegangen, denn ich benutze ja eigentlich ICC. GCC wäre halt ne
Alternative, weil Upgrades kein Geld kosten.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
oder du hast nicht richtig portiert.. man muss eben wissen was ein
compiler für code erwartet damit er damit was anfangen kann...

und da der gcc 16bit lastig ist kann ich mir das sehr gut vorstellen...
zumal du da haufenweise bit operationen drinnen haben wirst.. da muss
man sich beim gcc was überlegen damit der code klein und schnell
wird...

aja welche optimierung hast du "damals" genommen ?? Os wäre gut
gewesen.. O2 auch aber O3 (höchste optimierungsstufe) macht dir
größeren code wie Os !!! siehe doku.. damit ließe sich das schon
erklären...

73

Autor: Peter Dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leute Leute,

Ich hab doch nicht über den WINAVR gemeckert.

Das mit der 16Bit-Lastigkeit und dem größer werdenden Code sind reine
Feststellungen, mehr nicht.

Und seit dem Mega8 und mit dem Mega168 habe ich auch genügend
Reserven.

Ein Vergleich mit IAR / ICC wäre natürlich mal interessant.

Worin der WINAVR unschlagbar ist, ist natürlich, daß ich ihn auf allen
PCs (Werkstatt, Büro, Home, Notebook) laufen lassen kann ohne 4
Lizenzen kaufen zu müssen oder ständig mit nem Dongle durch die Gegend
zu rennen.


Peter

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

Bewertung
0 lesenswert
nicht lesenswert
> Ein Vergleich mit IAR / ICC wäre natürlich mal interessant.

IAR hat eine Menge niedlicher netter kleiner Optimierungen, die
in der Summe schon nochmal 10 % oder so ausmachen, je nach Quellcode
natürlich.  Man merkt ihm einfach an, dass er ein auf Controller
gut zugeschnittener Compiler ist, anders als GCC, der ja aus einer
völlig anderen Welt kommt.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
du verkennst die eigentlichen vorteile ;)

1: du kannst am schlepp linux in der werkstatt win95 und in der fa xp
haben und immer den geleichen compiler verwenden

2: du kannst mit deinen avrs spielen und wenns dich überkommpt
schnellmal einen arm ausprobieren mit den gleichen compiler,ide,...

3: du musst nicht hoffen, dass auf deinem zukünftigen os dein compiler
noch rennt...

und 4: du hast den code ;)

73

Autor: Josef Zimmermann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So jetzt muss auch noch meine Senf dazu geben.

Es greift zu kurz, wenn man einen Compiler nur nach Laufzeit und
Resourcenbedarf beurteilt.

Ich halte den gcc (z.Zt. Version 3.3.5, i386, ARM7, AVR) für einen der
besten Compiler mit denen ich bisher gearbeitet habe.

ICC hatte ich auch mal für einen Monat im Test und der ist ok. Man
bekommt sehr schnell sein Programm auf die Beine. Aber die tollen
Tools/Menues zur Configuration von Baudrate, Timer, etc.  nageln dich
auch ziemlich auf diesen Compiler fest. Besser finde ich da eine
universelle Lösung die mir per Makro/Präprozessor die passenden
Einstellungen für UART, Timer, etc. aus den defines für Baudrate und
CPU-Clock ableiten. Und zum Finden von Informationen in Dokus und
Sourcen gibt es Suchfunktionen.

IAR habe ich vor Urzeiten mal auf einem H8/500 laufen gehabt und fand
ihn gut. Vor einem Jahr habe ich den IAR für den PIC18 getestet und
konnte keine Schwächen finden. Aber ein kurzer Test ist noch kein
komplettes Projekt. Auf jeden Fall hat der Compiler einen guten Ruf.

Es gibt nach meiner Einschätzung einen Menge Compiler die deutlich
schlechter sind als der gcc. Und der gcc könnte durch unserer Mithilfe
sogar noch etwas besser werden.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Manche Optimierungen anderer Compiler werden durch Verletzung von
ANSI-Definitionen erkauft.

So habe ich auch schon mal 8-bit "int" als Standard gesehen. ANSI
verlangt 16bit.

Oder arithmetische Operationen werden nur dann 16bittig ausgeführt,
wenn mindestens einer der Operanden 16bittig ist. ANSI hingegen
verlangt, dass das Erghebnis so ist, als wäre sie immer mindestens
16bittig ausgeführt worden - was er tatsächlich macht ist egal. Das
macht beispielsweise bei
   uint8_t a, b;
   if (a + 1 > b)
einen Unterschied. Bei a=255 ist es hier absolut nicht egal, ob das in
8bit oder 16bit gerechnet wird.

Autor: Werner Hoch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab mal in einer meiner Dateien nachgesehen und dort wird sehrwohl
swap verwendet.
Auszug aus der lst-Datei.

void
lcd_data_command(uint8_t signal) {
 360:  1f 93         push  r17
 362:  18 2f         mov  r17, r24
  /* delete the data port pins */ /* put high nibble to data port */
  LCD_DATA_PORT = (LCD_DATA_PORT & ~LCD_DATA_MASK) | (signal >> 4);
 364:  88 b3         in  r24, 0x18  ; 24
 366:  80 7f         andi  r24, 0xF0  ; 240
 368:  91 2f         mov  r25, r17
 36a:  92 95         swap  r25
 36c:  9f 70         andi  r25, 0x0F  ; 15
 36e:  89 2b         or  r24, r25
 370:  88 bb         out  0x18, r24  ; 24
  lcd_enable();
 372:  ed df         rcall  .-38       ; 0x34e
  /* delete the data port pins *//* put low nibble to data port */
  LCD_DATA_PORT = (LCD_DATA_PORT & ~LCD_DATA_MASK) | (signal & 0x0f);

 374:  88 b3         in  r24, 0x18  ; 24
 376:  80 7f         andi  r24, 0xF0  ; 240
 378:  1f 70         andi  r17, 0x0F  ; 15
 37a:  81 2b         or  r24, r17
 37c:  88 bb         out  0x18, r24  ; 24
  lcd_enable();
 37e:  e7 df         rcall  .-50       ; 0x34e
 380:  8c e5         ldi  r24, 0x5C  ; 92
 382:  00 00         nop
 384:  81 50         subi  r24, 0x01  ; 1
 386:  e9 f7         brne  .-6        ; 0x382
  /* the lcd-controller needs some execution time */
  lcd_delay_50us();
}
 388:  1f 91         pop  r17
 38a:  08 95         ret

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, nie war vielleicht etwas übertrieben, aber swap/mul wird seltener
angewendet als es möglich und sinnvoll wäre.
In meinen LCD Routinen kam es z.B. garnicht vor, ehe ich den Code etwas
anpasst habe.

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

Bewertung
0 lesenswert
nicht lesenswert
mul wird immer verwendet, wenn es möglich ist.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wie ich oben schon so schän erwähnt habe...

> man muss eben wissen was ein
> compiler für code erwartet damit er damit was anfangen kann...

und das gilt für jeden compiler.. der kann ja nicht ahnen was du dir da
vorstellst was rauskommen soll..

73

Autor: JarJar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
ich hab den Thread hier mit etwas Erstaunen gelesen und frage mich grad
ernsthaft ob WinAVR die Mühe wert ist. Stimmt das wirklich das so
rudimentäre Befehle wie Swap und (noch schlimmer) der Hardware
Multiplyer nicht unterstütz werden? Für rechenintensive Projekte ist
sowas doch ne absolute Katastrophe, auch noch wenn alles, ob nötig oder
nicht, erstmal in 16 Bit umgewandelt wird.
Kostenlose OpenSource hin oder her, aber wenn sowas wichtiges nicht
unterstützt wird kann man das doch für ernsthafte Projekte doch allen
ernstes vergessen.
Sollte ich irgendwas mißverstanden haben bitte ich um Entschuldigung
und bitte um Aufklärung

JarJar

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

beide Befehle werden, sofern sinnvoll und möglich auch verwendet. Es
kann aber durchaus mal eine Situation vorkommen in der der Compiler
nicht "bemerkt" das ein swap oder mul effizienter wäre. Ich hab aber
mitlerweile einige Projekte mit dem avrgcc realisiert die auch munter
vor sich hin verkauft werden. IMHO kann man mit dem AVRGCC sehr
ordentlich arbeiten auch ohne ständig in den ASM-Outputs rumzulesen.

Matthias

Autor: JarJar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, wäre aber schon schön zu wissen ob die (beschrängten) Ressourcen des
 Controllers vernünftig ausgenutzt werden oder ob durch zu großzügigen
Umgang damit wertvolle Rechenleistung weggeschmissen wird. Hab mal ein
einfaches neuronales Netz programmiert. Wenn da der Code nicht optimal
ist schmeißt man unendlich viel Leistung weg (es geht mir nichtmal um
Programmgröße). Wenn ich schon lese das arithmetische Operationen
erstmal auf 16 Bit aufgeblasen werden stellen sich meine Nackenhaare
auf und alle Alarmglocken schrillen.
Für 95% aller Anwendungen mag das vielleicht nicht in's Gewicht
fallen, aber wenn man dann doch mal drauf angewiesen ist wüsste ich
gern was Sache ist

Autor: Werner B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@JarJar,

... gibt man jemandem den keinen Finger (wobei das meiner Meinung nach
schon fast 9,45 Finger sind), will er gleich die ganze Hand!

Ein vergleich mit Autos erklärt den menschen meist am besten um was es
geht.

Wer von einem VW Käfer im Gelände/Offroad die geiche Leistung erwartet
wie von enem Hummer Jeep hat nun mal auf die falsche Karte gesetzt -
DAFÜR IST ER NUN MAL NICHT GEBAUT. Aber man kann trotzdem ganz gut auf
schlammigen Feldwegen fahren - aber eben nicht in extremem Gelände.

Autor: JarJar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry wenn ich Deine Meinung nicht teile. Wenn ich ein Auto fürs Gelände
will kauf ich mir natürlich ein entsprechendes.
Aber wenn ich einen Compiler für einen Controller will dann erwarte ich
von dem Compiler (egal ob der von Porsche oder VW kommt) das der die
verfügbaren Ressourcen des Controllers nutzt. Die sind ja da. Ein VW
Käfe hat die Ressource "Geländeaufhänung" und "4WD" nunmal nicht
damit man ins Gelände kann.
Ich würde eher sagen das man das zb mit einem Satz Schraubenschlüssel
vergleichen kann bei dem eine Größe fehlt. Mit dem kann man auch nur so
lange arbeiten bis man mal eine Schraube bearbeiten muß für die der
Schlüssel fehlt.

Worum es mir geht ist das vorhandene Befehle genutzt werden undunnötige
Operationen wie das unnötige Aufblasen auf 16 Bit vermieden werden. Ich
rede noch gar nicht über hochintelligente Strategien um schlechten Code
noch halbwegs schnell und kompakt zu machen. Keine Optimierung sondern
nur die grundsätzliche Ausnutzung des vorhandenen

Autor: JarJar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur um das klarzustellen: ich weiß wie schwierig es ist einen Compiler
zu programmieren. Wenn Befehle in der Regel verwendet werden und nur in
seltenen Fällen mal anders umgesetzt werden hab ich durchaus Verständnis
und werde mich in dem Fall selbst um Besserung bemühen, aber Ressourcen
wie Befehle, spezielle Register oder was auch immer aus Bequemlichkeit
zu ignorieren find ich sch****. Ein Mikrocontroller hat begrenze
Ressourcen und wenn mit denen leichtfertig umgegangen wird finde ich
das weniger lustig. Wenn ich zwei 8 Bit Werte auf einem Mega8
multipliziere erwarte ich schon das da auch wirklich je 8 Bit in den
Hardware Multiplyer geschoben werden und der mir einen 16 Bit Wert
liefert. Aus dem was ich hier gelesen hab entnehme ich das dem nicht so
ist. Korrigiert mich bitte wenn ich mich irren

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

es werden nur die Operationen (AFAIK hauptsächlich Logik) in 16 Bit
ausgeführt die laut C-Standard auch in 16 Bit ausgeführt werden
müssen. Multiplikationen gehören nicht dazu. Aus

while(1)
{
    o1 = PINA;
    o2 = PINB;

    r = o1 * o2;

    PORTC = r & 0xFF;
    PORTD = (r / 256) & 0xFF;
}

wird

    o1 = PINA;
  96:  99 b3         in  r25, 0x19  ; 25
    o2 = PINB;
  98:  86 b3         in  r24, 0x16  ; 22
    r = o1 * o2;
  9a:  98 9f         mul  r25, r24
  9c:  c0 01         movw  r24, r0
  9e:  11 24         eor  r1, r1
    PORTC = r & 0xFF;
  a0:  85 bb         out  0x15, r24  ; 21
    PORTD = (r / 256) & 0xFF;
  a2:  89 2f         mov  r24, r25
  a4:  99 27         eor  r25, r25
  a6:  82 bb         out  0x12, r24  ; 18
  a8:  f6 cf         rjmp  .-20       ; 0x96

Sicher nicht ideal (aus der Sicht eines ASM-Programmierers) aber die
Multiplikation wird nicht mit 16 Bit Operanden durchgeführt.

Und wenn dir die Qualität des kostenlosen Tools nicht ausreicht steht
dir immer noch der Weg zum IAR-Compiler offen. Vor diesem Weg liegt
halt die Brücke mit mehreren k€ Brückenmaut :-)

Matthias

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Compiler kostet dich nichts und liefert m.E. meist eine passable
Code-Qualität ab. Optimal ist er nicht - aber GCC hat gewisse
Grundvoraussetzungen an die Zielmaschine (z.B. >= 16bit ISA,
hinreichende Anzahl Register) die von AVR nicht alle erfüllt werden.
Übrigens auch nicht von diversen anderen GCC Targets aus dem
Microcontroller-Sektor, wie 6811/12 oder R8c/M16c/M32c (die Anzahl
Register ist zu gering), auch da ist die Umsetzung dementsprechend
nicht optimal.

Es hindert dich jedoch niemand daran, der Compiler dementsprechend
umzubauen. Der Quellcode ist frei verfügbar.

Andererseits hindert dich auch niemand daran, einen Compiler zu kaufen.
Ich würde dir aber raten, ihn vorher auszuprobieren. Er wird deinen
Ansprüchen wahrscheinlich auch nicht gerecht werden.

Autor: JarJar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin kein Mensch der sich nicht von vernünftigen Argumenten
überzeugen läßt ;)
Ich hab ja auch gesagt: bitte korrigiert mich wenn ich falsch liege.
Ich hab mich am Betreff und an einigen anderen Aussagen gestört die
nicht richtig wiederlegt wurden. Anscheinend ist das weitestgehen
geklärt. Ich werd mich mal damit befassen.

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

Bewertung
0 lesenswert
nicht lesenswert
> Ich hab ja auch gesagt: bitte korrigiert mich wenn ich falsch liege.

Kein Compiler wird wirklich das erzeugen können, was du mit der Hand
als Assemblercode zimmern könntest, wenngleich heutige Compiler oft
genug ganz gut an derartigen Code herankommen und ihn streckenweise
auch übertreffen (weil der generierte Assemblercode dann derart
schlecht lesbar ist, dass ihn selbst eingefleischte Assemblerfreaks
nicht so aufschreiben würden).

Der AVR-GCC dürfte nach allem, was man in diversen Forums und
Mailinglisten lesen kann, durchaus drastisch im oberen Drittel der
Compiler rangieren, was die Effektivität des generierten Codes
betrifft.  Ein wirklich guter kommerzieller Compiler, der (im
Gegensatz zu GCC) von vornherein auf Microcontroller ausgerichtet ist,
kann ihn andererseits auch beinahe auf jedem Gebiet übertreffen.  Nach
allem, was ich gehört und gelesen habe, dürfte der IAR Embedded
Workbench da wohl der Einzige sein.  Wie dir schon gesagt wurde, den
bezahlst du nach KiloEUR -- pro Arbeitsplatz, versteht sich (nichtmal
MS Terminal Server wird akzeptiert).  Von anderen Hostbetriebssystemen
als Windows sprechen wir natürlich dabei auch nicht.

Falls du dir den circa 10fachen (für ein ansehnlich großes Projekt)
Wartungsaufwand für reine Assemblerprogrammierung leisten kannst oder
willst: deine Sache.  Für > 10000 Stück Jahresproduktion mag das auch
kommerziell angehen, wenn man vielleicht den nächstkleineren AVR
benutzen kann dadurch, aber privat ist mir meine Freizeit zu schade,
einen derartigen Aufwand zu treiben.  Das habe ich in den letzten
Jahren genau einmal gemacht (in diesem Falle mit einem PIC), danach
wusste ich, dass ich im 3. Jahrtausend nicht mehr alles mit einem
Assembler programmieren möchte.  (Dadurch bin ich dann zu den AVRs
gekommen.)

Autor: JarJar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab doch gesagt das es jetzt ok ist. Ich hätte nur ernste Zweifel gehabt
wenn wirklich grundlegende Funktionen wie der Hardware Mul nicht
unterstützt würden. Hab keinen Bock mir das selber zu stricken.
Wie gesagt, es ging mir nicht um nen idealen Optimizer oder 100%
optimalen und fehlerfreien Code sondern nur darum das grundsätzlich
erstmal alle wichtigen Funktionen verwendet werden.
Mit einem Compiler der nicht immer optimalen Code erzeugt kann ich
leben, aber nicht mit einem der nicht alles (wichtige) kann

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

Bewertung
0 lesenswert
nicht lesenswert
Peter:

> Was mich auch wundert ist, daß bei jeder neuen WINAVR-Version der
> erzeugte Code immer größer wird.

http://lists.gnu.org/archive/html/avr-gcc-list/200...

Man könnte beim Anblick der "Summary"-Zeile den Eindruck gewinnen,
dass es bis zu 3.4.x immer besser geworden wäre und mit 4.x
schlechter. ;-)

Das ist das, was ich mit den Pauschalisierungen meinte...

Autor: JarJar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ist an dem Eindruck falsch? Ich kenne die Unterschiede in den
Versionen nicht.
Ich habe aber schon bei anderen Compilern beobachtet das ein Programm
ohne Zutun von Compilerversion zu Compilerversion größer werden kann.
Einmal mußte ich das schmerzlich feststellen als ein Programm nicht
mehr in nen Mega8 gepasst hat was vorher der Fall war. Ursache in dem
Fall waren Bugfixes und Ergänzungen an einzelnen Funktionen

Autor: Fritz Ganter (fritzg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab auch mal rumgemeckert warum (in einer speziellen Funktion) der
gcc4.x schlechter optimiert (Code wurde einiges größer) als der
gcc3.x.
Als ich aber für die Takte nachgezählt habe, wurde klar dass der Code
schneller war, es war halt eine tricky-Schleifenoptimierung.
Ich hab auch Funktionen die ca. 10mal so gross wurden, was aber durch
-funroll-loops gewollt war, hat mir den Faktor 2 in der Geschwindigkeit
der IR-Datenübertragung gebracht.

Codegrösse ist bei mir nebensächlich, schnell muss er sein.

@JarJar:
der GCC verwendet mul und swap

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie muss ich das umschreiben, damit swap bzw. mul verwendet wird ?

LCD_port|=(LCD_port&15)|((byte&15)*16);

Im Moment wird daraus ein Shift.

Autor: JarJar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, ist natürlich ne Frage welche Optimierung einem lieber ist,
Codegröße oder Tacktzahl. Beides gleichzeitig geht halt so gut wie gar
nicht. In meinem Fall (anderer Compiler) gab es gar keine
Optimierungsmöglichkeiten, aber die Codegröße ist bei Updates
gelegentlich angewachsen was in dem Fall wirklich an Bugfixes oder
erweiterten Funktionen lag, nicht an der Änderung der
Optimierungsstrategie.
Wenn man sich die oben genannte Tabelle aber anschaut kann man sich
schon wundern. Ich nehme mal an die vordere Zahl ist jeweils Flash, die
hintere ist der Ram Bedarf. Die Version 4.0 ist beim Gesamtflash nur
unwesentlich besser als als 3.2 und beim Ram sogar deutlich schlechter.
Aber es ist ja auch nur eine Auswahl (vermutlich zufällig ausgesuchter)
Routinen was nichts über das Gesamtergebnis der jeweiligen Programme
aussagen muß.
Wenn die Vergrößerungen auf Bugfixes oder andere Verbesserungen
zurückzuführen sind kann denke ich jeder damit leben, es sei denn
dadurch bekommt er ein Programm wirklich nicht mehr in einen
Controller. Richtig bitter wird es wenn es keinen größeren Controller
mehr gibt

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Richtig bitter wird es wenn es keinen größeren Controller
mehr gibt"

Dann hat man den Fehler schon vorher gemacht. Wer beispielsweise ein
Programm auf MSP430 schreibt, das schon in der ersten produktiven
Version bei 30-40KB liegt, der hat den Fehler schon bei der Auswahl des
Controllers gemacht.

Autor: Fritz Ganter (fritzg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei mir macht er kein Shift (gcc 4.01, mit -O2):

4038 15be 9091 0000     lds r25,uhrneu
1836:wecker.c      **** LCD_port|=(LCD_port&15)|((byte&15)*16);
 4040                 .LM521:
 4041 15c2 28B3          in r18,56-0x20
 4042 15c4 88B3          in r24,56-0x20
 4043 15c6 8F70          andi r24,lo8(15)
 4044 15c8 9295          swap r25
 4045 15ca 907F          andi r25,0xf0
 4046 15cc 982B          or r25,r24
 4047 15ce 292B          or r18,r25
 4048 15d0 28BB          out 56-0x20,r18

Autor: JarJar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum? Wenn man ein Programm geschrieben hat das im Prinzip fertig ist
und von allen Ressourcen in einen Mega32 passt und vielleicht noch
100-200 Bytes Luft sind, warum sollte man dann (vor allem in der
Massenfertigung) einen doch etwas teureren Mega64 nehmen?
Wenn man dann nur ne klitzekleine Änderung machen muß die normal keinen
Einfluß auf die Programmgröße hat und das Programm auf einmal nicht mehr
in den Controller passt ist man auf deutsch gesagt der Gearschte, es sei
denn man hat sich die ältere Version des Compilers aufgehoben.
In der Industrie wird keiner einen größeren Controller einsetzen nur
um die Möglichkeit auszuschließen das das Programm aufgrund von
Compileränderungen auf einmal nicht mehr reinpasst

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn das alles wie festgefroren ist... Aber wozu dann neu übersetzen?

Oft ergeben sich mit der Zeit nicht klitzekleine Dinge. Es werden
etliche neue Funktionen nachgefragt. Der Benutzerführung/Bedienung
versteht bloss der Programierer, muss also umgeschrieben/erweitert
werden. Usw. An sowas dachte ich. Das trifft vor allem grössere
Programme - bei Kleinkram von ein paar KB Code ändert eher wenig.

Ansonsten: Wirf bei einem Upgrade den alten Compiler nicht weg sondern
installieren die neue Version neben der alten. Grad bei GCC ist das
problemlos möglich. Ob das bei typischen Windows-Compilern mit
entsprechender Verwendung der Registry auch möglich ist?

Autor: Fritz Ganter (fritzg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wieso aufbehalten? Auf ftp://ftp.gnu.org/gnu/gcc/ bekommst noch alle
Versionen zurück bis ins Jahr 1992 :-)

Autor: JarJar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah, cool. Jetzt muß man nur noch nen Internetzugang haben wenn man man
nen alten Compiler braucht ;)
Also ich hab meistens 2-3 Versionen bei mir auf der Platte und einmal
hat mir das echt geholfen weil ein Update einen Fehler in einer
Funktion eingebaut hatte den es vorher nicht gab. Alte Version
installiert, neu compiliert und schon lief's wieder

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"In der Industrie wird keiner einen größeren Controller einsetzen"

Nein, sicher nicht. Aber wenn er eine Controller-Familie auswählt, die
schon jetzt knapp dran ist, also kein grösseres Modell existiert, dann
hat er niedrige Kosten jetzt gegen erhebliche Umstiegskosten später
eingetauscht. Kann man machen, aber man muss sich über solche
Folgeeffekte dann im Klaren sein.

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

Bewertung
0 lesenswert
nicht lesenswert
> LCD_port|=(LCD_port&15)|((byte&15)*16);

> Im Moment wird daraus ein Shift.

Vermutlich wird er davon ausgehen, dass der shift schneller wäre (was
ohne hardware multiplier ja auch wirklich der Fall ist).

> Wenn man sich die oben genannte Tabelle aber anschaut kann man sich
> schon wundern. Ich nehme mal an die vordere Zahl ist jeweils Flash,
> die hintere ist der Ram Bedarf. Die Version 4.0 ist beim Gesamtflash
> nur unwesentlich besser als als 3.2 und beim Ram sogar deutlich
> schlechter.

4.0 ist halt eine Entwicklerversion, ein dot-zero release eben.  Wenn
du den Thread mal weiterverfolgst, gibt's noch ein Followup, in dem
Dmitry den 4.1-CVS mit getestet hat, der kommt wieder auf den Werten
heraus, die zuvor als Bestes auftauchten.

> Aber es ist ja auch nur eine Auswahl (vermutlich zufällig
> ausgesuchter) Routinen was nichts über das Gesamtergebnis der
> jeweiligen Programme aussagen muß.

Genau so ist es.  Vom ,,Gesamteindruck'' realer Applikationen her
bestätigte sich nämlich (was ja zu Peters Bemerkung führte) der Trend,
dass GCC 3.4.x besser als seine Vorgänger sei, durchaus gar nicht.
Die Matrix zeigt aber, dass er es in einzelnen Teilen durchaus ist
(nur daher hatte ich den Link gepostet).

> Warum? Wenn man ein Programm geschrieben hat das im Prinzip fertig
> ist und von allen Ressourcen in einen Mega32 passt und vielleicht
> noch 100-200 Bytes Luft sind, warum sollte man dann (vor allem in
> der Massenfertigung) einen doch etwas teureren Mega64 nehmen?

Weil nach dem Gesetz von Murphy der schlimmste aller Bugs erst kurz
nach der Serieneinführung auftaucht und der Bugfix just 201 Bytes
benötigen wird -- ganz unabhängig von der Compilerversion, versteht
sich.

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.