Mikrocontroller: "Compiler-Optimizer-Fehler" finden?

[Michael Schwingen]

On 2015-05-11, Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> wrote:

Beim gcc: -ffunction-sections -fdata-sections -Wl,--gc-sections

Liest sich so, als ob das nicht so ohne weiteres den gewünschten Effekt
brächte, sondern nur die _Vorbereitung_ dafür, das machen zu können.

Das ist keine Vorbereitung: man übersetzt alles mit diesen Flags, linkt, und
das Ergebnis paßt.

D.h. eine Bibliothek oder eine Objekt-Datei muß so kompiliert werden,
damit _später_ die Funktionen selektiv entnommen werden können. Wurde sie
das nicht, geht es nicht.

Natürlich - das gilt auch ohne ...-sections: wenn eine Bibliothek mit
unpassenden Compilerflags übersetzt wurde, kann man die überhaupt nicht
benutzen.

Bei --gc-sections ist das weniger schlimm: der Fallback (Bibliothek wird
dann halt wieder objekt-weise dazugelinkt) funktioniert, beim restlichen
Code hat man trotzdem den Vorteil.

Und als nette Ergänzung gibt's dann noch den Nachsatz, daß damit die
Objekt-Dateien größer würden, was nicht so schlimm wäre - aber daß auch die
so erstellten _Anwendungen_ größer würden, und zudem _langsamer_.

Das ELF-File wird größer, der Code nicht. Ich benutze das seit Jahren für
Code, der ins Flash kommt - der schrumpft spürbar.

vorstellen. Daß das von den gängigen Debuggern auch ungern gesehen werden
kann, dagegen schon...

Ich hatte noch keine Probleme damit. gdb kann es problemlos - und soweit ich
das sehe, ist das vollständig vom ELF-Format abgedeckt, das ja beliebige
sections kann.

Linker, der einfach strunzdumm alle Objekte aus einer statischen Library
mit einbindet, ist immernoch standardkonform.

Eben. Und so war das halt lange Zeit.

Und? das ist kein Grund, warum das prinzipiell immer so sein müßte.

cu
Michael

 

[Sieghard Schicktanz]

Hallo Johannes,

Du schriebst am Sun, 10 May 2015 12:59:04 +0200:

Butter bei die Fische: Lass mal einen Profiler auf einen Compilevorgang
laufen. Du wirst sehen, dass die Zeit fĂźr die Block Reads (also Zeit im
Kern) im einstelligen Prozentbereich liegt. Wegen Include-Guards braucht

FĂźr die gesamte Bearbeitungszeit ist nicht nur die "Zeit im Kern" relevant,
sondern die tatsächlich vergehende Zeit ("Wall Clock Time").

man keine schnellere und leistungsfähigere Hardware, das ist kompletter
Nonsense.

Wäre nachzuweisen, daß das keinen Einfluß hat. Jedenfalls wurde die
angesprochenen Optimierungen parallel zur Verfßgbarkeit leistungsfähigerer
Hardware eingefĂźhrt.

Wenn das Ziel sein soll, bestimmte Dateien nur einmalig einzulegsen,
muss *jede* Programmiersprache irgendeinen Mechanismus bereitstellen, um

Ja, sicher - das kann nachträglich mit einer Compiler-Funktion erreicht
werden oder schon von Anfang an in der Definition des Aufbaus der
verarbeiteten Programmquellen.

Fßr die _allgemeine_ Bewertung ist auch die Praktikabilität ein
Kriterium, und die wird davon durchaus beeinflußt. Die Fähigkeit zur
Erstellung von vorgegebenen Funktionen ist davon natßrlich unabhängig.

Das heißt, du kennst Fälle, in denen sich C nur deshalb als untauglich
disqualifiziert hat, weil der Parsing-Mechanismus der Header-Files Ăźber

Nein, heißt das nicht. Es heißt nur, daß es ein Zusatzaufwand ist, zunächst
einmal die Header-Dateien ßberhaupt erstellen (und später "pflegen") zu
müssen und zudem darauf achten zu müssen, daß sie auch die richtigen
"Include-Guards" enthalten. Und mit der angesprochenen Compiler-Optimierung
diesbezüglich muß der Programmierer auch noch darauf achten, daß seine
Header _ausschließlich_ so "geschützte" Statements enthalten und nicht noch
ein paar andere Informationen, die ohne weiteres mehrfach verarbeitet
werden kĂśnnten oder anderweitig unkritisch gemacht wurden.

(Provokativ: Was macht ein solcher Compiler z.B., wenn er ein Header-File
zu verarbeiten bekommt, das _zwei_ [oder mehr] Include-Guard-geschĂźtzte
BlÜcke enthält?)

--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

 

[Reinhardt Behm]

On 11.05.2015 08:22, Sieghard Schicktanz wrote:

Hallo Johannes,

Du schriebst am Sun, 10 May 2015 12:59:04 +0200:

Butter bei die Fische: Lass mal einen Profiler auf einen Compilevorgang
laufen. Du wirst sehen, dass die Zeit fĂźr die Block Reads (also Zeit im
Kern) im einstelligen Prozentbereich liegt. Wegen Include-Guards braucht

FĂźr die gesamte Bearbeitungszeit ist nicht nur die "Zeit im Kern" relevant,
sondern die tatsächlich vergehende Zeit ("Wall Clock Time").

man keine schnellere und leistungsfähigere Hardware, das ist kompletter
Nonsense.

Wäre nachzuweisen, daß das keinen Einfluß hat. Jedenfalls wurde die
angesprochenen Optimierungen parallel zur Verfßgbarkeit leistungsfähigerer
Hardware eingefĂźhrt.

Wobei daraus kein kausaler Zusammenhang folgt. Man hat halt die Compiler
optimiert und zufällig wurde auch die Hardware schneller.

Wenn das Ziel sein soll, bestimmte Dateien nur einmalig einzulegsen,
muss *jede* Programmiersprache irgendeinen Mechanismus bereitstellen, um

Ja, sicher - das kann nachträglich mit einer Compiler-Funktion erreicht
werden oder schon von Anfang an in der Definition des Aufbaus der
verarbeiteten Programmquellen.

Und das macht welchen Unterschied aus?

Fßr die _allgemeine_ Bewertung ist auch die Praktikabilität ein
Kriterium, und die wird davon durchaus beeinflußt. Die Fähigkeit zur
Erstellung von vorgegebenen Funktionen ist davon natßrlich unabhängig.

Das heißt, du kennst Fälle, in denen sich C nur deshalb als untauglich
disqualifiziert hat, weil der Parsing-Mechanismus der Header-Files Ăźber

Nein, heißt das nicht. Es heißt nur, daß es ein Zusatzaufwand ist, zunächst
einmal die Header-Dateien ßberhaupt erstellen (und später "pflegen") zu
müssen und zudem darauf achten zu müssen, daß sie auch die richtigen
"Include-Guards" enthalten. Und mit der angesprochenen Compiler-Optimierung
diesbezüglich muß der Programmierer auch noch darauf achten, daß seine
Header _ausschließlich_ so "geschützte" Statements enthalten und nicht noch
ein paar andere Informationen, die ohne weiteres mehrfach verarbeitet
werden kĂśnnten oder anderweitig unkritisch gemacht wurden.

Erstes mal gehĂśrt zu sauberer Softwareentwicklung viel mehr, als sich
nur an den Rechner zu setzen und irgendwas einzutippen - z.B.
Requirements schreiben, Testcases entwerfen, uvam. Da macht das
Schreiben von Header-Dateien den Bock auch nicht fett. Zudem kann man
Header-Dateien sehr gut zu Dokumentation benutzen, siehe Doxygen.

Es ist auch nicht die Aufgabe einer Programmiersprache, den
Programmierer vor seiner eigenen Dummheit zu schĂźtzen. Der von Dir
beschriebene Unfug wĂźrde bei keinem Code-Review durchgehen. DafĂźr sollte
es immer Standards (z.B. MISRA) geben, die sowas nicht zulassen.

(Provokativ: Was macht ein solcher Compiler z.B., wenn er ein Header-File
zu verarbeiten bekommt, das _zwei_ [oder mehr] Include-Guard-geschĂźtzte
BlÜcke enthält?)

Eigentlich sollte der Compiler einen der speziellen Befehle ausfĂźhren,
wie EIO (execute ignorant operator). ;-)

--
Reinhardt

 

[Hans-Peter Diettrich]

Bernd Laengerich schrieb:

Scheint eine andere Version zu sein. Der AIM 65 hatte AFAIR nur einen
auskodierten 4K-ROM-Steckplatz, wenn Monitor und BASIC installiert
waren, die anderen ROMs von Pascal waren unter 32kB und nicht auskodiert.

Basic hatte ich nicht drauf, war wohl in der Standard-Version nicht
enthalten, oder ich hatte stattdessen FORTH ausgewählt.

DoDi

 

[Reinhardt Behm]

On 12.05.2015 02:41, Sieghard Schicktanz wrote:

Hallo Reinhardt,

Du schriebst am Mon, 11 May 2015 20:29:36 +0800:

Wäre nachzuweisen, daß das keinen Einfluß hat. Jedenfalls wurde die
angesprochenen Optimierungen parallel zur VerfĂźgbarkeit
leistungsfähigerer Hardware eingefßhrt.

Wobei daraus kein kausaler Zusammenhang folgt. Man hat halt die Compiler
optimiert und zufällig wurde auch die Hardware schneller.

Ein kausaler Zusammenhang wohl nicht, aber die Softwerker haben sich halt
darauf verlassen, daß der schon langdauernde Trend bei der Hardware weiter
anhielte.

Und deshalb den Compiler schneller gemacht??

Ja, sicher - das kann nachträglich mit einer Compiler-Funktion erreicht
werden oder schon von Anfang an in der Definition des Aufbaus der
verarbeiteten Programmquellen.

Und das macht welchen Unterschied aus?

Den, daß im einen Fall die Interface-Defintionen in separaten Dateien
separat gepflegt und separat verarbeitet werden mĂźssen und nicht bei der
Verarbeitung geprßft werden kÜnnen, während im anderen Fall alles zusammen
in derselben Datei steht und beim Kompilieren auch so verarbeitet und
gegeneinander geprĂźft werden kann.

Wenn die .h in ihrer zugehĂśrigen .c Datei eingebunden wird - und das
sollte sie, wird das auch gegeneinander geprĂźft.

Ja toll, ich will nur schnell shene, wie eine Funktion heißt und wie sie
aufgerufen wird. Bei C genĂźgt ein Blick in die (kurze) .h. Bei anderen
muss ich mir den gesamten Source ansehen.
Meine Zeit ist wichtige als die Zeit die der Compiler braucht.

Und jetzt komm nicht damit, dass bei Deinem Pascal die IDE fĂźr Dich
macht. Ich will nicht fĂźr jedes Projekt einen anderen Editor benutzen -
besonders nicht den - meist schlechten - von irgendeiner IDE.

....
Erstes mal gehĂśrt zu sauberer Softwareentwicklung viel mehr, als sich
nur an den Rechner zu setzen und irgendwas einzutippen - z.B.

Sicher

Requirements schreiben, Testcases entwerfen, uvam. Da macht das
Schreiben von Header-Dateien den Bock auch nicht fett. Zudem kann man

Es macht zwar "den Bock [] nicht fett", aber es ist eine zusätzliche
Fehlerquelle.

Wobei einige der "Fehlerquellen" von Dir konstruiert werden.

Header-Dateien sehr gut zu Dokumentation benutzen, siehe Doxygen.

Dazu braucht man keine seapraten Header-Dateien. Andere Programmiersprachen
(perl, anyone?) kĂśnnen das ohne genauso, wenn nicht besser.

Es ist auch nicht die Aufgabe einer Programmiersprache, den
Programmierer vor seiner eigenen Dummheit zu schĂźtzen. Der von Dir
....
Eigentlich sollte der Compiler einen der speziellen Befehle ausfĂźhren,
wie EIO (execute ignorant operator). ;-)

Das würde die Anzahl der C-Programmierer sicher auf ein überschaubares Maß
reduzieren...

Eher nicht, denn gute Programmierer machen keine solchen Unfug. Die
anderen sollten eher Videospiele spielen, wenn sie den Computer benutzen.

--
Reinhardt

 

[Reinhardt Behm]

On 12.05.2015 04:38, Michael Schwingen wrote:

Ach nee, stimmt, da habe ich übersehen, daß in C ja so viel per Pointer
läuft - und das (hoffentlich nur vorübergehende) Chaos an Wortlängen und
Ausrichtungen kann auch zu schaffen machen...
Und das auch noch unabhängig von der Programmiersprache.

Wie werden bei Pascal var Parameter übergeben? Das passiert genauso, nur
wird es vor Dir versteckt.

--
Reinhardt

 

[Stefan Reuther]

Sieghard Schicktanz wrote:

Du schriebst am Sun, 10 May 2015 12:59:04 +0200:
Butter bei die Fische: Lass mal einen Profiler auf einen Compilevorgang
laufen. Du wirst sehen, dass die Zeit fĂźr die Block Reads (also Zeit im
Kern) im einstelligen Prozentbereich liegt. Wegen Include-Guards braucht

FĂźr die gesamte Bearbeitungszeit ist nicht nur die "Zeit im Kern" relevant,
sondern die tatsächlich vergehende Zeit ("Wall Clock Time").

Sofern der Compiler tatsächlich nennenswert Zeit auf die Platte wartet
(nach dem ersten Durchlauf tut er das normalerweise nicht mehr) hilft
'make -j8'.

Fßr die _allgemeine_ Bewertung ist auch die Praktikabilität ein
Kriterium, und die wird davon durchaus beeinflußt. Die Fähigkeit zur
Erstellung von vorgegebenen Funktionen ist davon natßrlich unabhängig.

Das heißt, du kennst Fälle, in denen sich C nur deshalb als untauglich
disqualifiziert hat, weil der Parsing-Mechanismus der Header-Files Ăźber

Nein, heißt das nicht. Es heißt nur, daß es ein Zusatzaufwand ist, zunächst
einmal die Header-Dateien ßberhaupt erstellen (und später "pflegen") zu
müssen und zudem darauf achten zu müssen, daß sie auch die richtigen
"Include-Guards" enthalten.

Hier hast du nen Groschen, kauf dir nen richtigen Editor.

Ich hab seit Jahren keine Include-Guards mehr geschrieben, die setzt
mein Editor automatisch ein, wenn ich eine neue *.h-Datei aufmache
(inkl. projektspezifischem "CONFIDENTIAL (c) Firma" Header und allem
Brimborium).

Dass man den Header separat von der Implementation pflegt ist ein
Vorteil, man trennt Schnittstelle und Realisierung. In Pascal Ăźbrigens
auch, nur dass das da etwas unĂźbersichtlicher beides in einer Datei
stattfindet. In Java trennt man dann gleich gar nicht mehr.


Stefan

 

[Holger]

Guido Grohmann schrieb:

Herr winterhoff, soll ich hier öffentlich machen, wie sie im
Repdata-Forum auftetreten sind? Soll ich ihre alten Beiträge von ca.
1998 herausuchen, in denen sie mich ohne Anlaß als dumm bezeichnet haben?

Dann ist Manfred Winterhoff nicht der einzige, der mit diesem
Repdata-Forum seine Probleme hatte. Ich erinnere mich an ein defektes
Chassis für einen Telefunken-TV, der immer wieder mal blaue Streifen
über den Bildschirm zuckeln ließ. Ich fand den Fehler sehr schnell. Es
war ein IC auf dem Videomodul, das AD-Wandler enthält, von denen einer
defekt war. Natürlich war ich der böse "Laie" und wurde massiv angemacht
dafür. Was mich nicht hinderte, mein Gerät dennoch zu reparieren.

Solch ein Forum ist einfach unvergeßlich. Schöne Grüße an deine Freunde
Uwe S., braunelektro und vor allem aber den Thomsonfreak.

Für mich ist dieses Forum seit langem erledigt.

Holger

 

[Stefan Reuther]

Sieghard Schicktanz wrote:

Du schriebst am Sun, 10 May 2015 12:02:05 +0200:
Selektives Einbinden _einzelner_ Funktionen aus Objekten?
...
Beim gcc: -ffunction-sections -fdata-sections -Wl,--gc-sections

Liest sich so, als ob das nicht so ohne weiteres den gewĂźnschten Effekt
brächte, sondern nur die _Vorbereitung_ dafßr, das machen zu kÜnnen.
D.h. eine Bibliothek oder eine Objekt-Datei muß so kompiliert werden,
damit _später_ die Funktionen selektiv entnommen werden kÜnnen. Wurde sie
das nicht, geht es nicht.

Das gilt fĂźr den gcc. Bei anderen Compilern muss man wirklich nur einen
Linkerschalter setzen und die sägen dann die Sections so klein.

Und als nette Ergänzung gibt's dann noch den Nachsatz, daß damit die
Objekt-Dateien größer würden, was nicht so schlimm wäre - aber daß auch die
so erstellten _Anwendungen_ größer würden, und zudem _langsamer_.

Die gestrippte Applikation wird dafĂźr kleiner. Und was anderes als die
Größe der gestrippten Applikation (=das, was im Flash landet) vergleicht
man nicht sinnvoll.

Sonst mĂźsstest du sinnigerweise deine Projekte immer unter "c:\"
ablegen, denn da werden die Objektdateien kleiner, als wenn sie unter
"c:\users\sieghard\my projects\new arduino project\src" liegen, weil der
Compiler die Pfadnamen in die Debuginformationen packt.


Stefan

 

[Sieghard Schicktanz]

Hallo Michael,

Du schriebst am 11 May 2015 06:44:03 GMT:

[gcc: -ffunction-sections]

Liest sich so, als ob das nicht so ohne weiteres den gewĂźnschten Effekt
brächte, sondern nur die _Vorbereitung_ dafßr, das machen zu kÜnnen.

Das ist keine Vorbereitung: man Ăźbersetzt alles mit diesen Flags, linkt,
und das Ergebnis paßt.

Ja, genau das meinte ich. Eine Bibliothek oder eine Objekt-Datei muß
_vorher_ so ßbersetzt werden, damit sie der Linker später funktions-
selektiv einbinden kann. D.h. bereits vorhandene (Fremd-) Bibliothken
und ähnliches kÜnnen nicht so genutzt werden.

unpassenden Compilerflags Ăźbersetzt wurde, kann man die Ăźberhaupt nicht
benutzen.

HÜrt sich bisserl schräg an - wenn der Aufruf eines Unterprogramms passt,
dann _sollte_ der enthaltene Maschinencode reichlich unabhängig von der
Umgebung arbeiten kĂśnnen. Das gilt natĂźrlich nicht fĂźr hardware-nahe
Funktionen, aber eine reine Datenverarbeitung kann da doch allenfalls
geschwindigkeitsmäßig aus dem Rahmen fallen.
Ach nee, stimmt, da habe ich übersehen, daß in C ja so viel per Pointer
läuft - und das (hoffentlich nur vorßbergehende) Chaos an Wortlängen und
Ausrichtungen kann auch zu schaffen machen...
Und das auch noch unabhängig von der Programmiersprache.

die so erstellten _Anwendungen_ größer würden, und zudem _langsamer_.

Das ELF-File wird größer, der Code nicht. Ich benutze das seit Jahren für
Code, der ins Flash kommt - der schrumpft spĂźrbar.

Dann stimmt die Ergänzung also nicht? Daß die Ladse-Informationen
umfangreicher werden dürften, läßt sich ja schon aus der Bezeichnung des
Schalters vermuten, der Codeumfang im Arbeitsspeicher sollte allerdings
damit kleiner werden - deshalb hatte mich der Nachsatz ja so verwundert.
Und auf die Geschwindigkeit sollte das doch überhaupt keinen Einfluß haben
- wie soll das zustandekommen? Oder stimmt das etwa auch nicht? warum steht
das dann da?

vorstellen. Daß das von den gängigen Debuggern auch ungern gesehen
werden kann, dagegen schon...

Ich hatte noch keine Probleme damit. gdb kann es problemlos - und soweit

Möglicherweise könnte es Überläufe in den Tabellen geben - eine "Section"
pro Funktion macht halt bei vielen Funktionen viele "Sections", alos große
Tabellen, und damit evtl. _zu_ große Tabellen.

Eben. Und so war das halt lange Zeit.

Und? das ist kein Grund, warum das prinzipiell immer so sein müßte.

Eben. Gut, daß es auch regulär anders geht - jetzt müßte das "nur noch" die
Voreinstellung werden.

--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

 

[Sieghard Schicktanz]

Hallo Reinhardt,

Du schriebst am Mon, 11 May 2015 20:29:36 +0800:

Wäre nachzuweisen, daß das keinen Einfluß hat. Jedenfalls wurde die
angesprochenen Optimierungen parallel zur VerfĂźgbarkeit
leistungsfähigerer Hardware eingefßhrt.

Wobei daraus kein kausaler Zusammenhang folgt. Man hat halt die Compiler
optimiert und zufällig wurde auch die Hardware schneller.

Ein kausaler Zusammenhang wohl nicht, aber die Softwerker haben sich halt
darauf verlassen, daß der schon langdauernde Trend bei der Hardware weiter
anhielte.

Ja, sicher - das kann nachträglich mit einer Compiler-Funktion erreicht
werden oder schon von Anfang an in der Definition des Aufbaus der
verarbeiteten Programmquellen.

Und das macht welchen Unterschied aus?

Den, daß im einen Fall die Interface-Defintionen in separaten Dateien
separat gepflegt und separat verarbeitet werden mĂźssen und nicht bei der
Verarbeitung geprßft werden kÜnnen, während im anderen Fall alles zusammen
in derselben Datei steht und beim Kompilieren auch so verarbeitet und
gegeneinander geprĂźft werden kann.

....

Erstes mal gehĂśrt zu sauberer Softwareentwicklung viel mehr, als sich
nur an den Rechner zu setzen und irgendwas einzutippen - z.B.

Sicher

Requirements schreiben, Testcases entwerfen, uvam. Da macht das
Schreiben von Header-Dateien den Bock auch nicht fett. Zudem kann man

Es macht zwar "den Bock [] nicht fett", aber es ist eine zusätzliche
Fehlerquelle.

> Header-Dateien sehr gut zu Dokumentation benutzen, siehe Doxygen.

Dazu braucht man keine seapraten Header-Dateien. Andere Programmiersprachen
(perl, anyone?) kĂśnnen das ohne genauso, wenn nicht besser.

Es ist auch nicht die Aufgabe einer Programmiersprache, den
Programmierer vor seiner eigenen Dummheit zu schĂźtzen. Der von Dir
....
Eigentlich sollte der Compiler einen der speziellen Befehle ausfĂźhren,
wie EIO (execute ignorant operator). ;-)

Das würde die Anzahl der C-Programmierer sicher auf ein überschaubares Maß
reduzieren...

--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

 

[Michael Schwingen]

On 2015-05-11, Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> wrote:

Das ist keine Vorbereitung: man übersetzt alles mit diesen Flags, linkt,
und das Ergebnis paßt.

Ja, genau das meinte ich. Eine Bibliothek oder eine Objekt-Datei muß
_vorher_ so übersetzt werden, damit sie der Linker später funktions-
selektiv einbinden kann. D.h. bereits vorhandene (Fremd-) Bibliothken
und ähnliches können nicht so genutzt werden.

unpassenden Compilerflags übersetzt wurde, kann man die überhaupt nicht
benutzen.

Hört sich bisserl schräg an - wenn der Aufruf eines Unterprogramms passt,
dann _sollte_ der enthaltene Maschinencode reichlich unabhängig von der
Umgebung arbeiten können. Das gilt natürlich nicht für hardware-nahe
Funktionen, aber eine reine Datenverarbeitung kann da doch allenfalls
geschwindigkeitsmäßig aus dem Rahmen fallen.

Dann probier' mal, eine Bibliothek, die mit der falschen ABI erzeugt wurde,
zu einem Programm dazuzulinken (z.B. ARM hard-float vs. soft-float, oder
andere Calling Conventions auf PowerPC). Wenn Du Pech hast und die ABI für
eine Plattform nicht extern spezifiziert ist, kann es unmöglich sein,
Komponenten zusammenzulinken, die mit verschiedenen Compilerversionen
erzeugt wurden.

Code, den man zusammenlinken will, muß man passend mit kompatiblen
Compilerflags übersetzen. Da ist das mit den sections kein echtes Problem.

Ach nee, stimmt, da habe ich übersehen, daß in C ja so viel per Pointer
läuft - und das (hoffentlich nur vorübergehende) Chaos an Wortlängen und
Ausrichtungen kann auch zu schaffen machen...
Und das auch noch unabhängig von der Programmiersprache.

Die ABI (z.B. ARM oder PowerPC EABI) legt z.B. fest, welche Parameter in
welchen Registern übergeben werden, und welche Register vom
Aufrufer/Aufgerufenen verändert werden dürfen. Die Spezifikationen dazu
sind im Fall ARM und PowerPC unabhängig von der Sprache definiert, und es
gibt teilweise mehrere - da kann C überhaupt nichts dafür.

Schalters vermuten, der Codeumfang im Arbeitsspeicher sollte allerdings
damit kleiner werden - deshalb hatte mich der Nachsatz ja so verwundert.
Und auf die Geschwindigkeit sollte das doch überhaupt keinen Einfluß haben
- wie soll das zustandekommen? Oder stimmt das etwa auch nicht? warum steht
das dann da?

Auf üblichen Plattformen sollte es durch bessere Cacheausnutzung eher
schneller werden.

Ich hatte noch keine Probleme damit. gdb kann es problemlos - und soweit

Möglicherweise könnte es Überläufe in den Tabellen geben - eine "Section"
pro Funktion macht halt bei vielen Funktionen viele "Sections", alos große
Tabellen, und damit evtl. _zu_ große Tabellen.

Nicht nach dem Linken - da bleiben nur die üblichen ~5-10 sections übrig
(.text, .data, .rodata, .bss, ...) - schau' Dir halt mal aktuelle
Linkerscripte für den gnu-ld an.

cu
Michael

 

[Guenther Wenninger]

Holger <me@privacy.org> schrieb:

Guido Grohmann schrieb:

Herr winterhoff, soll ich hier Ăśffentlich machen, wie sie im
Repdata-Forum auftetreten sind? Soll ich ihre alten Beiträge von ca.
1998 herausuchen, in denen sie mich ohne Anlaß als dumm bezeichnet haben?

Dann ist Manfred Winterhoff nicht der einzige, der mit diesem
Repdata-Forum seine Probleme hatte. Ich erinnere mich an ein defektes
Chassis fĂźr einen Telefunken-TV, der immer wieder mal blaue Streifen
über den Bildschirm zuckeln ließ. Ich fand den Fehler sehr schnell. Es
war ein IC auf dem Videomodul, das AD-Wandler enthält, von denen einer
defekt war. NatĂźrlich war ich der bĂśse "Laie" und wurde massiv angemacht
dafßr. Was mich nicht hinderte, mein Gerät dennoch zu reparieren.

Solch ein Forum ist einfach unvergeßlich. Schöne Grüße an deine Freunde
Uwe S., braunelektro und vor allem aber den Thomsonfreak.
[...]

Ähnliches kann man sich auch in den Foren auf mikrocontroller.net
anhĂśren. Vermutlich sind da die gleichen "das kannst du eh nicht",
"das geht nicht", "lass das lieber jemand anderen machen"-Leute
unterwegs.

Ich vermute, die sind alle bei ihrer ersten Blinkschaltung nicht
weiter gekommen und kĂśnnen nicht glauben, dass andere mehr auf
dem Kasten haben als sie selbst...

Grüße,
grw

--
For reply: Remove the additional chars from the local part.

 

[Holger]

Guenther Wenninger schrieb:

Holger <me@privacy.org> schrieb:
Guido Grohmann schrieb:

Herr winterhoff, soll ich hier Ăśffentlich machen, wie sie im
Repdata-Forum auftetreten sind? Soll ich ihre alten Beiträge von ca.
1998 herausuchen, in denen sie mich ohne Anlaß als dumm bezeichnet haben?
Dann ist Manfred Winterhoff nicht der einzige, der mit diesem
Repdata-Forum seine Probleme hatte. Ich erinnere mich an ein defektes
Chassis fĂźr einen Telefunken-TV, der immer wieder mal blaue Streifen
über den Bildschirm zuckeln ließ. Ich fand den Fehler sehr schnell. Es
war ein IC auf dem Videomodul, das AD-Wandler enthält, von denen einer
defekt war. NatĂźrlich war ich der bĂśse "Laie" und wurde massiv angemacht
dafßr. Was mich nicht hinderte, mein Gerät dennoch zu reparieren.

Solch ein Forum ist einfach unvergeßlich. Schöne Grüße an deine Freunde
Uwe S., braunelektro und vor allem aber den Thomsonfreak.
[...]

Ähnliches kann man sich auch in den Foren auf mikrocontroller.net
anhĂśren. Vermutlich sind da die gleichen "das kannst du eh nicht",
"das geht nicht", "lass das lieber jemand anderen machen"-Leute
unterwegs.

Ich vermute, die sind alle bei ihrer ersten Blinkschaltung nicht
weiter gekommen und kĂśnnen nicht glauben, dass andere mehr auf
dem Kasten haben als sie selbst...

Ich weiß nicht. Diese Fernsehhansel prahlten zwar mit ihren Lötkünsten,
aber sie verstanden das PAL-System nicht, anhand dessen ich ihnen den
Fehler erklärte. Und insbesondere der Thomsonfreak ist mir noch in
bester Erinnerung: Er weigerte sich, mir das gesuchte IC zu verkaufen.
Sowas gibt es nur fĂźr Fachleute. Ich hab das dann via Ebay bekommen.

Ich vermute, es sind einfach Radio- und Fernsehtechniker, die jede vom
potentiellen Kunden selbst vorgenommene Reparatur fĂźr einen Angriff auf
ihre wirtschaftliche Existenz sehen, weswegen sie ja die "Techniker"
seien, in einer Welt, die ansonsten aus "Laien" besteht, die sich am
besten noch nicht mal eine Suppe kochen dĂźrfen, weil man sich daran ja
verbrühen könnte. Man muß solche Leute ganz unter sich lassen.

Mit dem mikrocontroller.net habe ich noch keine größeren Erfahrungen
gemacht. Ich tendiere sowieso dazu, meine eigenen Entwicklungen und
meine Reparaturen nicht mehr in Foren zu diskutieren, auch und gerade
nach Erfahrungen in de.sci.electronics, weil sich meine Bereitschaft zur
Schlammschlacht doch inzwischen in sehr in Grenzen hält. Von daher wßrde
ich auch den Mikrocontrollern(.net) nicht unbedingt mitteilen, was ich
mit Mikrocontrollern mache.

Holger

 

[Reinhardt Behm]

On 13.05.2015 02:43, Sieghard Schicktanz wrote:

Hallo Reinhardt,

Du schriebst am Mon, 11 May 2015 21:54:18 +0800:

Wie werden bei Pascal var Parameter Ăźbergeben? Das passiert genauso, nur
wird es vor Dir versteckt.

Das _kann_ genauso passieren und wird auch gerne so gemacht.
Festgeschrieben ist es nicht, es wären andere Methoden zulässig.
Der tatsächliche Unterschied kommt aber bei der _Nutzung_ dieser Parameter
- anders als bei C muß man _nicht_ ständig daran denken, einen
Dereferenzierungsoperator an die interne Variable anzupappen, sondern
benutzt die genauso, wie sie in der Parameterliste bezeichnet wird.
Die Variable ist fĂźr den Programmierer also _kein_ Pointer, sondern eine
echte Variable, die beim Programmlauf dann als Äquivalent der in der
Parameterliste Ăźbergebenen Variablen fungiert.

Zeig mir mal eine andere Methode, den Parameter (beim Callee) zu ändern,
ohne die Adresse zu haben.
Es ging auch nicht darum, sondern um Deine Darstellung, dass gerade
Pointer als Parameter ein großes Problem seien, wenn Teile des Programms
mit anderen Flags Ăźbersetzt wurden. Ich wollte Dir nur aufzeigen, dass
das kein C-spzifisches Problem ist. Wenn es denn Ăźberhaupt eins ist.

--
Reinhardt

 

[Reinhardt Behm]

On 13.05.2015 02:59, Sieghard Schicktanz wrote:

Hallo Stefan,

Du schriebst am Mon, 11 May 2015 18:19:16 +0200:

Sofern der Compiler tatsächlich nennenswert Zeit auf die Platte wartet
(nach dem ersten Durchlauf tut er das normalerweise nicht mehr) hilft
'make -j8'.

SchĂśn, dann ist die Kiste sicher dicht.

Sie soll ja auch arbeiten.
Ich mache das ständig und meine Rechner ist während der Zeit nicht dicht.

["Include-Guards"]

Hier hast du nen Groschen, kauf dir nen richtigen Editor.

Danke, kein Bedarf.

Ich hab seit Jahren keine Include-Guards mehr geschrieben, die setzt
mein Editor automatisch ein, wenn ich eine neue *.h-Datei aufmache

Und wenn Du mal 'ne Include-Datei brauchst, die _keinen_ "Guard" enthalten
soll / darf? Ja, kann mir's denken: "das kommt praktisch nicht vor".

Drei Zeilen lĂśschen ist jetzt aiuch nicht die Welt.

--
Reinhardt

 

[Hans-Peter Diettrich]

Reinhardt Behm schrieb:

Wie werden bei Pascal var Parameter übergeben? Das passiert genauso, nur
wird es vor Dir versteckt.

Verstehe den Unterschied zwischen Referenzen und Pointern. Den gibt es
auch in C++.

DoDi

 

[Johannes Bauer]

On 12.05.2015 16:40, Hans-Peter Diettrich wrote:

Reinhardt Behm schrieb:

Wie werden bei Pascal var Parameter übergeben? Das passiert genauso,
nur wird es vor Dir versteckt.

Verstehe den Unterschied zwischen Referenzen und Pointern. Den gibt es
auch in C++.

Und bei deinen scheißarroganten Antworten wundert es dich, dass du
selbst nicht mit Samthandschuhen angefasst wirst? Merkst du überhaupt,
dass du bereits in deinem ersten Satz Reinhardts Unverständnis implizierst?

Gruß,
Johannes

--

Wo hattest Du das Beben nochmal GENAU vorhergesagt?
Zumindest nicht öffentlich!

Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>

 

[Stefan Reuther]

Sieghard Schicktanz wrote:

Ja, sicher - das kann nachträglich mit einer Compiler-Funktion erreicht
werden oder schon von Anfang an in der Definition des Aufbaus der
verarbeiteten Programmquellen.

Und das macht welchen Unterschied aus?

Den, daß im einen Fall die Interface-Defintionen in separaten Dateien
separat gepflegt und separat verarbeitet werden mĂźssen und nicht bei der
Verarbeitung geprßft werden kÜnnen, während im anderen Fall alles zusammen
in derselben Datei steht und beim Kompilieren auch so verarbeitet und
gegeneinander geprĂźft werden kann.

Der Unterschied zwischen C und den Borlandschen Pascals ist an der
Stelle, dass man in beiden zwar ungefähr das gleiche schreibt (nämlich
einen Deklarations- und einen Implementationsteil), nur dass man das in
Pascal in die selbe Datei klatscht (INTERFACE- und IMPLEMENTATION-Teil).

Mit dem Ergebnis, dass man die Schnittstellenbeschreibung immer schĂśn
manuell schreiben muss, wenn man ein Objectfile weitergeben will. Java
hat das gleiche Problem. In C nimmt man einfach das Headerfile, das man
schon hat, und das dann auch - vom Compiler geprĂźft - garantiert zur
Implementierung passt.

Requirements schreiben, Testcases entwerfen, uvam. Da macht das
Schreiben von Header-Dateien den Bock auch nicht fett. Zudem kann man

Es macht zwar "den Bock [] nicht fett", aber es ist eine zusätzliche
Fehlerquelle.

Eine Fehlerquelle ist es nur fĂźr Leute, die nicht bei der Sache sind.
FĂźr andere ist es eine MĂśglichkeit, Fehler zu vermeiden.

Header-Dateien sehr gut zu Dokumentation benutzen, siehe Doxygen.

Dazu braucht man keine seapraten Header-Dateien. Andere Programmiersprachen
(perl, anyone?) kĂśnnen das ohne genauso, wenn nicht besser.

Perl unterscheidet sich hier u.a. dadurch von C/Pascal/Java, dass es da
keine Objectfiles gibt.


Stefan

 

[Stefan Reuther]

Sieghard Schicktanz wrote:

Du schriebst am 11 May 2015 06:44:03 GMT:
[gcc: -ffunction-sections]
Liest sich so, als ob das nicht so ohne weiteres den gewĂźnschten Effekt
brächte, sondern nur die _Vorbereitung_ dafßr, das machen zu kÜnnen.

Das ist keine Vorbereitung: man Ăźbersetzt alles mit diesen Flags, linkt,
und das Ergebnis paßt.

Ja, genau das meinte ich. Eine Bibliothek oder eine Objekt-Datei muß
_vorher_ so ßbersetzt werden, damit sie der Linker später funktions-
selektiv einbinden kann. D.h. bereits vorhandene (Fremd-) Bibliothken
und ähnliches kÜnnen nicht so genutzt werden.

Das trifft auf den gcc zu, aber nicht auf alle C-Compiler dieser Welt.
Wie gesagt, es gibt auch welche, da macht man einfach im Linker den
Haken bei "unbenutzte Funktionen rauswerfen" und dann macht der das.

Das braucht aber eben eine geeignete ABI, die den Compiler zwingt, den
Code von vornherein entsprechend teilbar zu generieren. Auf RISC-
Architekturen ist das eher sinnvoll mĂśglich als auf x86.

unpassenden Compilerflags Ăźbersetzt wurde, kann man die Ăźberhaupt nicht
benutzen.

HÜrt sich bisserl schräg an - wenn der Aufruf eines Unterprogramms passt,
dann _sollte_ der enthaltene Maschinencode reichlich unabhängig von der
Umgebung arbeiten kĂśnnen. Das gilt natĂźrlich nicht fĂźr hardware-nahe
Funktionen, aber eine reine Datenverarbeitung kann da doch allenfalls
geschwindigkeitsmäßig aus dem Rahmen fallen.

Mit einem geeigneten Linker bekommst du problemlos i386- und ARM-Code zu
einem Binary zusammengebaut.

die so erstellten _Anwendungen_ größer würden, und zudem _langsamer_.

Das ELF-File wird größer, der Code nicht. Ich benutze das seit Jahren für
Code, der ins Flash kommt - der schrumpft spĂźrbar.

Dann stimmt die Ergänzung also nicht? Daß die Ladse-Informationen
umfangreicher werden dürften, läßt sich ja schon aus der Bezeichnung des
Schalters vermuten, der Codeumfang im Arbeitsspeicher sollte allerdings
damit kleiner werden - deshalb hatte mich der Nachsatz ja so verwundert.

Das hängt alles ziemlich von den Innereien der jeweiligen Zielplattform
ab. Beim "klassischen" Linken kann der Compiler z.B. Informationen
nutzen, dass drei globale Variablen "static int i, j, k;" immer direkt
hintereinander im Speicher liegen. Das kann er nicht mehr, wenn er damit
rechnen muss, dass der Linker die Variable 'j' rauswirft, und kann z.B.
zusätzliche GOT-Zugriffe bedeuten.

Eben. Und so war das halt lange Zeit.

Und? das ist kein Grund, warum das prinzipiell immer so sein müßte.

Eben. Gut, daß es auch regulär anders geht - jetzt müßte das "nur noch" die
Voreinstellung werden.

Noch sind genug Leute unterwegs, die erwarten, dass der Compiler bei
'static int i, j, k;' auch 6 oder 12 Bytes Speicher anlegt. Gerade im
Embedded-Umfeld. FĂźr die gibt es genug GrĂźnde gegen so eine Voreinstellung.


Stefan