Forum: Compiler & IDEs avr-gcc alle c-Dateien im Ordner übersetzen und dann linken


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Michael D. (sirs)


Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Nachdem mein Atmel Studio ja buggt wie blöd (siehe anderer Thread) hab 
ich mal mit dem Programmers Notepad weiterprobiert. Die avr8-Toolchain 
ersetzt grad meine alte Toolchain -> damit kann der atxmegaa1u auch 
erkannt und programmiert werden (hello-wolrd-blink-led-Programm läuft).

Allerdings ist beim kompilieren mehrerer Dateien noch was faul:
Es wird nur das main-File kompiliert, nicht die anderen c-Files, die 
eingebunden sind. Dadurch kommen Fehler zustande weil er versucht Zeug 
einzubinden das er nicht übersetzt hat (hier zB eine usb_init-Funktion).
1
Linking: main.elf
2
avr-gcc -mmcu=atxmega128a1u -gdwarf-2 -DF_CPU=32000000UL -DF_USB=48000000UL -DBOARD=BOARD_ -DARCH=ARCH_ -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=main.o  -std=gnu99 -MMD -MP -MF .dep/main.elf.d main.o --output main.elf -Wl,-Map=main.map,--cref     -lm
3
main.o: In function `init':
4
C:\Users\xxxxxxx\Desktop\USB_ganz_einfach_mikrocontroller_net/main.c:29: undefined reference to `usb_init'
5
main.o: In function `main':
6
C:\Users\xxxxxxx\Desktop\USB_ganz_einfach_mikrocontroller_net/main.c:40: undefined reference to `cdc_rxb'

Den Aufruf des avr-gcc macht ein Makefile. Was muss man da dazufügen bzw 
ändern, damit er alle c-Dateien in diesem Ordner übersetzt? Habs schon 
mit "avr-gcc *.c" probiert, aber das führt zu Fehlern (wohl mit dem -o).

von Boris O. (bohnsorg) Benutzerseite


Bewertung
-1 lesenswert
nicht lesenswert
Da liest du dir am besten einmal etwas Makefile-Wissen an, bspw. bei 
O'Reilly[1] (oder Wikipedia, oder man-page). Es gibt auch hier ein 
https://www.mikrocontroller.net/articles/Beispiel_Makefile.

[1] https://www.oreilly.de/german/freebooks/rlinux3ger/ch133.html

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
Michael D. schrieb:
> Allerdings ist beim kompilieren mehrerer Dateien noch was faul:
> Es wird nur das main-File kompiliert, nicht die anderen c-Files, die
> eingebunden sind.

Wie sind sie denn eingebunden?

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


Bewertung
0 lesenswert
nicht lesenswert
Michael D. schrieb:
> Habs schon mit "avr-gcc *.c" probiert, aber das führt zu Fehlern (wohl
> mit dem -o).

Also,
1
avr-gcc -Os -mmcu=avr0815 -o foo.elf *.c

würde in der Tat funktionieren, aber ich stimme den anderen zu, etwas
Wissen um Makefiles kann nicht schaden.

Irgendwo sollte auch noch mein "Mfile" herumfliegen als kleiner
Makefile-Generator, falls dir das hilft.

von Michael D. (sirs)


Bewertung
0 lesenswert
nicht lesenswert
Wissen über Makefiles kann echt nicht schaden hab ich gemerkt. Läuft 
jetzt und kompiliert alles.
War allerdings erstmal die Billiglösung mit Auflisten der Files (noch 
sind es wenige). Das Makefile das ich hatte ist nämlich mit Variablen 
und so geschrieben, um den Aufruf selbst zusammenzubasteln. Hab aber 
jetzt grob verstanden wie sich das aufbaut.

von Udo (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
Noch als zusätzlicher Hinweis, falls du später mal optimieren musst: Die 
Reihenfolge der angegebenen c-Dateien hat starken Einfluss auf die Größe 
des Binarys.

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


Bewertung
0 lesenswert
nicht lesenswert
Udo schrieb:
> Die Reihenfolge der angegebenen c-Dateien hat starken Einfluss auf die
> Größe des Binarys.

Womit begründest du das?

von Udo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Begründen kann ich es nicht, weil mir das Wissen zu den genauen 
Vorgängen im Compiler fehlt. Es ist nur eine Beobachtung.

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Unter welchen Bedingungen beobachtest Du das?

Es ist nämlich nicht erklärbar; der Compiler übersetzt jedes Sourcefile 
separat, und erst der Linker fügt alle Objektdateien und benötigte 
Libraries zu einem gemeinsamen Klumpen zusammen.

Die Reihenfolge der Objektdateien hat dabei keinen Einfluss auf die 
Größe des Endergebnisses, wie auch, was soll da passieren?

von Udo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Naja, nimm einfach mal ein größeres Projekt und kompiliere es so wie 
hier vorgeschlagen. Also mit *.c
Dann nochmal mit separat angegebenen Files. Also z.B. 1.c 2.c 3.c oder 
auch 2.c 1.c 3.c und vergleiche.
Ich verwende -flto, eventuell hat das einen Einfluss. Ein einzelner 
gcc-Aufruf, also kompilieren und linken in einem.

Wie gesagt, erklären kann ich es auch nicht. Es ist einfach so.

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Das sollte sich mit der Untersuchung des Mapfiles aufklären lassen.

von Johann L. (gjlayde) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Udo schrieb:
> Naja, nimm einfach mal ein größeres Projekt und kompiliere es so wie
> hier vorgeschlagen. Also mit *.c
> Dann nochmal mit separat angegebenen Files. Also z.B. 1.c 2.c 3.c oder
> auch 2.c 1.c 3.c und vergleiche.
> Ich verwende -flto, eventuell hat das einen Einfluss. Ein einzelner
> gcc-Aufruf, also kompilieren und linken in einem.
>
> Wie gesagt, erklären kann ich es auch nicht. Es ist einfach so.

Der Unterschied rührt aber nicht von anderer Linkreihenfolge, sondern 
weil gerne mal vergessen wird, auch beim Linken Optimierungsoptionen wie 
-Os mitzugeben.  Das resultiert dann natürlich in einem "riesigen 
Unterschied", weil ohne -Os compiliert wird.

von Udo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hmm... Nein... ich mache doch alles in einem Rutsch. Mit einem einzelnen 
Aufruf. Da gebe ich nur 1x -Os an, aber das reicht doch?!

von Johann L. (gjlayde) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Udo schrieb:
> Hmm... Nein... ich mache doch alles in einem Rutsch. Mit einem einzelnen
> Aufruf. Da gebe ich nur 1x -Os an, aber das reicht doch?!

Und wie unterscheiden sich die beiden Szenarien denn, die du beschrieben 
hast?

Udo schrieb:
> Naja, nimm einfach mal ein größeres Projekt und kompiliere es so wie
> hier vorgeschlagen. Also mit *.c
> Dann nochmal mit separat angegebenen Files. Also z.B. 1.c 2.c 3.c oder
> auch 2.c 1.c 3.c und vergleiche.
> Ich verwende -flto, eventuell hat das einen Einfluss. Ein einzelner
> gcc-Aufruf, also kompilieren und linken in einem.
>
> Wie gesagt, erklären kann ich es auch nicht. Es ist einfach so.

Hab ich so verstanden, dass bei 2. ein separater Link-Aufruf erfolgt.

von Udo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Vielleicht habe ich mich missverständlich ausgedrückt?
1
avr-gcc [...] -Os -flto 1.c 2.c 3.c -mmcu=atmega168 -o a.elf
2
avr-gcc [...] -Os -flto 1.c 3.c 2.c -mmcu=atmega168 -o b.elf
3
avr-gcc [...] -Os -flto 2.c 1.c 3.c -mmcu=atmega168 -o c.elf
4
...

Die Varianten erzeugen nicht notwendigerweise gleich großen Code. Je 
nach Projekt macht das sogar einiges aus.

von Johann L. (gjlayde) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Wäre interessant, dies als Testfall zu haben, um zu untersuchen, woher 
der "starke Einfluss auf die Größe des Binarys" kommt.

von Erwin D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:
> Wäre interessant, dies als Testfall zu haben, um zu untersuchen,
> woher
> der "starke Einfluss auf die Größe des Binarys" kommt.

Vielleicht lädt Udo mal paar Files hoch, damit man das beschrieben 
Verhalten mal selbst nachvollziehen kann? Wäre ganz nett, denn ich kann 
mir auch keinen Grund für dieses Verhalten vorstellen.

von Udo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das tritt bei allen Projekten auf, die ich hier durch den Compiler jage 
und die mehr als eine .c-Datei haben, aber die Quelltexte stehen unter 
Schutz...

Daher nehme ich an, dass jeder es schnell selbst mal mit eigenen Werken 
testen kann.

Wenn ich die Zeit finde, kann ich demnächst trotzdem eventuell mal ein 
Dummy-Projekt zusammenschustern, dass den Effekt hervorruft. Dauert aber 
etwas.

Es sind übrigens alle Compilerversionen betroffen. 4.x, 5.x, 6.x.

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


Bewertung
0 lesenswert
nicht lesenswert
Udo schrieb:
> Daher nehme ich an, dass jeder es schnell selbst mal mit eigenen Werken
> testen kann.

Das ist es eben genau: wir alle hier können deine Beobachtung so
nicht nachvollziehen.

Um mal das Beispiel zu bringen, an dem ich sowieso gerade arbeite:
1
j@uriah 872% avr-gcc -mmcu=atmega644 -I. -gdwarf-2 -DF_CPU=8000000ul -Os -Wall -flto -std=c++11  ad8319.o Framebuffer.o I2C.o SSD1306.o  --output ad8319.elf     -lm
2
j@uriah 873% avr-size ad8319.elf
3
   text    data     bss     dec     hex filename
4
   1882       0       3    1885     75d ad8319.elf
5
j@uriah 874% avr-gcc -mmcu=atmega644 -I. -gdwarf-2 -DF_CPU=8000000ul -Os -Wall -flto -std=c++11 ad8319.o I2C.o SSD1306.o Framebuffer.o --output ad8319.elf -lm
6
j@uriah 875% avr-size ad8319.elf
7
   text    data     bss     dec     hex filename
8
   1882       0       3    1885     75d ad8319.elf
9
j@uriah 876% avr-gcc -mmcu=atmega644 -I. -gdwarf-2 -DF_CPU=8000000ul -Os -Wall -flto -std=c++11 I2C.o SSD1306.o Framebuffer.o ad8319.o --output ad8319.elf -lm
10
j@uriah 877% avr-size ad8319.elf  
11
   text    data     bss     dec     hex filename
12
   1882       0       3    1885     75d ad8319.elf

: Bearbeitet durch Moderator
von Udo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ist das auch so mit .c-Dateien anstatt .o-Dateien im Aufruf 
(Compile+Link in einem)?

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


Bewertung
0 lesenswert
nicht lesenswert
Udo schrieb:
> Ist das auch so mit .c-Dateien anstatt .o-Dateien im Aufruf
> (Compile+Link in einem)?

Mache ich nie.  Allerdings wüsste ich nicht, warum sich dadurch nun
was ändern sollte, denn der Compiler muss sie ja ohnehin erstmal
separat in Assemblercode umwandeln, diesen danach durch den Assembler
schieben, und erst dann kann er sie dem Linker vorwerfen.

von Udo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
...weil nicht sein kann, was nicht sein darf...? Versuche es doch mal. 
Wenn es keinen Unterschied macht, versuche ich in den nächsten Tagen mal 
ein Beispiel zu basteln.

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


Bewertung
0 lesenswert
nicht lesenswert
Udo schrieb:
> ...weil nicht sein kann, was nicht sein darf...?

Nein, weil ich lieber an meinem eigentlichen Projekt weiterkommen
möchte statt deine Behauptungen beweisen zu müssen.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
evtl. irgendwas was mit unbenutzen Funktionen und der Nichtverwendung 
von -ffunction-sections -Wl,--gc-sections vielleicht?

: Bearbeitet durch User
von Udo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich verwende noch eine ganze Reihe von Parametern. Ich habe das oben mit 
"[...]" deutlich gemacht, weil ich nicht weiß, was da jetzt Einfluss hat 
und was nicht.

Hier die Liste:

-DF_CPU=20000000UL
-fdata-sections
-ffunction-sections
-flto
-fpack-struct
-fshort-enums
-funsigned-bitfields
-funsigned-char
-Os
-std=gnu99
-Wl,-gc-sections

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Poste mal ein vollständige Beispiel.

Entweder hast Du einen Bug im gcc gefunden oder einen Bug in Deinem 
Build-Script oder in Deinen Sourcen (einmal zu oft weak verwendet?). Auf 
jeden Fall würd ich dem nachgehen wenn ich Du wäre. Vor allem würd ich 
als erstes mal nachschauen worin genau die unterschiedlichen Kompilate 
sich den nun unterscheiden.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Udo schrieb:

> -fpack-struct

Nutzlos, AVR packt immer auf 8-bit-Grenzen

Hält sich trotzdem beharrlich im Netz. ;-)

von Udo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Also, ich habe jetzt mal in mühevoller Kleinstarbeit (es sind mehr als 
hundert Funktionen) eine Funktion herausgesucht, die durch eine andere 
Reihenfolge größer wird.
In der .lss sieht man, dass die Unterschiede darin liegen, dass z.B. 
rcall zu call und rjmp zu jmp wird. Das sind dann schonmal je 2 Byte 
mehr. Das Ganze läppert sich halt über die vielen Funktionen.

von Oliver S. (oliverso)


Bewertung
0 lesenswert
nicht lesenswert
Na ja, da kommen dann vielleicht 100 - 200 Byte zusammen, denn manche 
Sprünge werden ja auch kleiner. Ein Unterschied mag da sein, riesig ist 
der nicht.

Johann L. schrieb:
> Der Unterschied rührt aber nicht von anderer Linkreihenfolge, sondern
> weil gerne mal vergessen wird, auch beim Linken Optimierungsoptionen wie
> -Os mitzugeben.

Hattest du nicht mal geschrieben, das gcc ab 5.irgendwas das nicht mehr 
braucht?

Oliver

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


Bewertung
0 lesenswert
nicht lesenswert
Udo schrieb:
> In der .lss sieht man, dass die Unterschiede darin liegen, dass z.B.
> rcall zu call und rjmp zu jmp wird.

Das ist zumindest erklärlich.  Allerdings müsste man wohl ziemlich
stark herumzirkeln, wenn man solche Effekte gezielt ausnutzen möchte.

von Johann L. (gjlayde) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Udo schrieb:
> In der .lss sieht man, dass die Unterschiede darin liegen, dass z.B.
> rcall zu call und rjmp zu jmp wird. Das sind dann schonmal je 2 Byte
> mehr. Das Ganze läppert sich halt über die vielen Funktionen.

Ok, also erwartete Effekte von -mrelax.  Was "starker Einfluss auf die 
Größe des Binarys" ist liegt ja im Auge des Betrachters :-)


Jörg W. schrieb:
> Allerdings müsste man wohl ziemlich stark herumzirkeln, wenn man solche
> Effekte gezielt ausnutzen möchte.

Vielleicht ohne Rumzirkeln mit LTO Partitioning und -flto=2 oder 
-flto=3?

https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-flto-936

Der Call-Tree wird dann aufgespalten in Komponenten; vielleicht kann 
dadurch erreicht werden, dass Funktionen, die in einer Call-Beziehung 
stehen, in der gleichen ltrans-Komponente landen und damit im Binary 
dichter beieibander, so dass die Wahrscheinlichkeit von RCALL erhöht 
wird.

Außerdem kann man an anderen Optionen rumspielen, die dafür bekannt 
sind, die Codegröße positiv zu beeinflussen wie -fno-caller-saves oder 
-fno-tree-loop-optimize

AVR-GCC-Codeoptimierung: Feinabstimmung der Optimizer

Oliver S. schrieb:
> Johann L. schrieb:
>> Der Unterschied rührt aber nicht von anderer Linkreihenfolge, sondern
>> weil gerne mal vergessen wird, auch beim Linken Optimierungsoptionen
>> wie -Os mitzugeben.
>
> Hattest du nicht mal geschrieben, das gcc ab 5.irgendwas das nicht mehr
> braucht?

Ja, ab GCC 5:
1
Command-line optimization and target options are now streamed on a
2
per-function basis and honored by the link-time optimizer. This change
3
makes link-time optimization a more transparent replacement of per-file
4
optimizations. It is now possible to build projects that require different
5
optimization settings for different translation units. Contrary to earlier
6
GCC releases, the optimization and target options passed on the link
7
command line are ignored.
8
9
Note that this applies only to those command-line options that can be
10
passed to optimize and target attributes. Command-line options affecting
11
global code generation (such as -fpic), warnings, optimizations affecting
12
the way static variables are optimized (such as -fcommon), debug output,
13
and --param parameters can be applied only to the whole link-time
14
optimization unit. In these cases, it is recommended to consistently
15
use the same options at both compile time and link time.

https://gcc.gnu.org/gcc-5/changes.html

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Udo schrieb:
> Das Ganze läppert sich halt über die vielen Funktionen.

Kannst Du mal Angaben machen, wieviel % das ausmacht.
Bei <1% würde ich da kein Gewese drum machen.

Ich benutze noch den WINAVR 2010. Die Codedichte ist für meine 
Anwendungen völlig ausreichend (typisch 5..30% Flash), inklusive float 
und sprintf.

von Udo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das macht ca. 2-3% aus und entscheidet bei zwei Projekten (ATmega168) 
darüber, ob das Binary noch gerade so in den Flash passt oder eben 
nicht.

Nachdem der Code schon bis an die Kotzgrenze optimiert war, haben wir, 
was die Optimierungsparameter angeht noch einen ziemlichen Aufwand 
getrieben und sogar ein internes Tool geschrieben, dass ca. 200 
Parameter nacheinander durchnudelt und dann die besten nochmal 
untereinander kombiniert. Das brachte durchschlagenden Erfolg.
Der nächste Schritt war halt, dass das mit der Reihenfolge aufgefallen 
ist. Angefangen hat es, glaube ich, damit, dass stupides Kompilieren mit 
"*.c" als Parameter auf manchen Rechnern anderen Code erzeugte... da 
wohl nach dem Einlesen der Dateiliste nicht sortiert wird und die 
Reihenfolge vom Dateisystem vorgegeben wird.

PS: -fno-caller-saves macht keinen Unterschied. Mit 
-fno-tree-loop-optimize braucht das Projekt ca. 200 Bytes mehr. :P

von Johann L. (gjlayde) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Udo schrieb:
> Mit -fno-tree-loop-optimize braucht das Projekt ca. 200 Bytes mehr.

Manchmal hilt die Kombination mit -fno-move-loop-invariants, aber es 
hängt natürlich auch viel vom konkreten Code ab, den wir ja nochj 
nichtmal auszugsweise kennen.

Manchmal hilft auch an der Registerpräperenz rumzudiddln mit -morder1/2. 
Vor allem wenn ihr verschiedene Optionen durchnudelt, und jeweils die 
kleinsten Objekte kombiniert (mit -flto funktioniert das dann aber 
offensichtlich nicht mehr).

: Bearbeitet durch User
von Udo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
-fno-move-loop-invariants gehört in der Tat zu den Parametern, welche 
unser Tool ausspuckt.

Was nicht gemacht wird, ist mit --param name=value irgendwelche 
Kostenfunktionen zu verändern. Das sind auch so unüberschaubar viele, 
dass es nicht so ein No-Brainer ist, wie einfach Parameter 
durchzunudeln.

von Johann L. (gjlayde) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
...und was auch helfen kann:  Im List-File nach "Nestern" von 32-Bit 
instruktionen LDS, STS suchen und indirekte Zugriffe forcieren.  Das ist 
natürlich nur dann sinnvoll, wenn das gleiche Objekt mehrfach 
zugegriffen wird, z.B. wenn man Daten als Struktur abgebildet hat oder 
viel 32-Bit Werte im Static Storage hat.

Der Quellcode wird dadurch zwar nicht schoner, aber wenn ein 
Legacy-Projekt dadurch übersetzbar wird, sei's eben drum...

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:
> Vielleicht ohne Rumzirkeln mit LTO Partitioning und -flto=2 oder
> -flto=3?

Welche Bedeutung hat das n in -flto=n? Ich kann keine Erwähnung finden 
in der Doku.

von Johann L. (gjlayde) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-flto-936
1
-flto[=n]
2
3
[...]
4
5
If you specify the optional n, the optimization and code generation done
6
at link time is executed in parallel using n parallel jobs by utilizing
7
an installed make program. The environment variable MAKE may be used to
8
override the program used. The default value for n is 1.

Der entsprechende Schalter scheint aber --param lto-partitions=2 zu 
sein, aber mit einem kleinen Projekt mit 2 simpel-Modulen wird trotzdem 
nur 1 Partition erzeugt... Vermutlich muss man da noch mehr drehen, z.B. 
--param lto-max-partition=,  Ob das irgendwie sinnvoll ist, kann ich 
nicht sagen; war nur so eine Idee wegen -mrelax...

von Oliver S. (oliverso)


Bewertung
-2 lesenswert
nicht lesenswert
Das Problem lässt sich mit einem einzigen Parameter komplett lösen:

-mmu=Mega328

Für den Zeitaufwand, den ihr (wer auch immer ihr ist) da schon betrieben 
habt, lassen sich viele passende Prozessoren kaufen.

In diesem Sinne...

Oliver

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


Bewertung
2 lesenswert
nicht lesenswert
Oliver S. schrieb:
> Das Problem lässt sich mit einem einzigen Parameter komplett lösen:

Davon abgesehen, dass du nichtmal in der Lage bist, die Option richtig
zu schreiben, hast du offenbar noch nie ein Industrieprojekt mit
bereits beim Kunden ausgerollter Hardware vor dir gehabt …  Dann wäre
es aber besser, wenn du dich mit derart klugen Ratschlägen ein wenig
zurück hieltest.

von Udo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Na, dann tausche mal tausende bestehende Geräte beim Kunden aus und 
wechsele die CPUs. Wegen eines Softwareupdates. Das wäre Irrsinn.

von Oliver S. (oliverso)


Bewertung
-1 lesenswert
nicht lesenswert
Je nun, ihr seit doch eh am Ende der Fahnenstange.

Selbst, wenn das aktuelle Update dann doch noch mit allen Tricks in den 
Prozessor passt, der Aufwand für das nächste wird noch mal exponentiell 
höher sein, ohne Garantie auf Erfolg.

Oliver

von Udo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich kann dir nur sagen: Selbst wenn kein Update unbedingt notwendig ist, 
neue Funktionen zu bieten und kleinere Fehler zu beseitigen, kommt immer 
super an. Dann kauft der Kunde eher auch neue Hardware beim gleichen 
Hersteller. Davon könnte sich so mancher TV-Hersteller eine Scheibe 
abschneiden. Wie schrottig die Software da oft ist und schon nach einem 
Jahr wird nix mehr dran gemacht! Das ist echt arm. Aber jetzt auch OT. 
;)

von Oliver S. (oliverso)


Bewertung
0 lesenswert
nicht lesenswert
Ist ja alles unbestritten richtig.

Wieviel Aufwand da gerechtfertigt ist, ist die unternehmerische 
Entscheidung desjenigen, der die unternehmerische Verantwortung dafür 
trägt. Wenns passt, dann habt ihr zumindest auf jeden Fall noch lange 
Zeit einen Job ;)

Oliver

: Bearbeitet durch User
von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Die besten Optimierungsergebnisse habe ich immer auf Sourcecode-Ebene 
erreicht. D.h. durch Vermeidung von Copy&Paste und bessere 
Modularisierung.
Es lohnt sich oft schon ab 2 ähnlichen Codesequenzen eine Unterfunktion 
daraus zu machen. Auch sollte man zusammenhängende Daten als Struct 
definieren, dann kann der Compiler sie über Pointer mit Displacement 
adressieren.

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]
  • [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.