Mikrocontroller: "Compiler-Optimizer-Fehler" finden?

[Sieghard Schicktanz]

Hallo Michael,

Du schriebst am 11 May 2015 20:38:17 GMT:

HÜrt sich bisserl schräg an - wenn der Aufruf eines Unterprogramms
passt, dann _sollte_ der enthaltene Maschinencode reichlich unabhängig
....
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

Ja, das ist wirklich schräg - die Übergabe von Parametern ist ein rechtes
Dickicht aus unterschiedlichen Konventionen, und jeder kann sich seine
eigene zusammenbrauen ...

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

Ok, zugestanden.

....

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.

Also ein irgendwie auf eigenartige Weise zustandegekommener Satz, der so
eigentlich garnicht stimmt? Dann sollte er (schleunigst) entfernt werden,
sonst nutzen noch weitere (Generationen von) Bibliotheksprogrammierern
diese MĂśglichkeiten nicht.

--
--
(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 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.

--
--
(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 21:51:35 +0800:

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??

Schneller als Nebeneffekt, zunächst aber vor allem komplexer, was ohne
leistungsfähigere Hardware nicht gegangen wäre.

....

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

Kann sie geprĂźft werden, in den Aspekten, die intern benutzt werden.
Also Funktionsprototypen und extern verfĂźgbare Variablen.

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.

Quatsch - wenn es, wie bei (ISO-) Pascal (bzw. Delphi) einen Interface-
Abschnitt gibt, steht dort alles relevante schĂś zusammengefasst und genauso
kurz wie in einem C-Header.

> Und jetzt komm nicht damit, dass bei Deinem Pascal die IDE fĂźr Dich

Quatsch². Die IDE ist bei Pascal genauso wichtig wie bei C. Nämlich
Ăźberhaupt nicht.

[Polemik]

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

Und wie hoch ist wohl der relative Anteil der _guten_ Programmierer im
Vergleich der Programmiersprachen? C wird vielen einfach vorgegeben, ob sie
wollen (und kĂśnnen) oder nicht - Nutzer anderer Sprachen suchen sich diese
wohl verhältnismäßig öfter nach ihren (teils auch bloß eingebildeten)
Kenntnissen aus.

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

 

[Sieghard Schicktanz]

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.

["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".

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

 

[Hans-Peter Diettrich]

Stefan Reuther schrieb:

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.

Kommt drsuf an, was Du unter Objectfile verstehst. Die Ăźbersetzten Units
(tpu, dcu...) enthalten das Interface noch (und mehr), kĂśnnen also
direkt weitergegeben werden. Für eine Verwendung in Fremdsprachen muß
man sowieso jedes Interface umschreiben, damit der jeweilige Compiler es
Ăźberhaupt verstehen kann.

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.

Zur Implementierung nur soweit alle im Header nicht aufgelisteten
Randbedingungen (Compiler Optionen, Target...) und die nicht ebenfalls
mitgelieferten #includes zum Object passen. API != ABI :-(

Dieses Problem hat man aber mit praktisch allen vorĂźbersetzten Modulen,
egal welcher Sprache. Eine Weitergabe ist nur sicher mĂśglich, wenn die
AusfĂźhrung in einer auf jeder Plattform identischen VM erfolgt, wie bei
Java.

DoDi

 

[Hans-Peter Diettrich]

Sieghard Schicktanz schrieb:

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

Sowas kann sogar nĂźtzlich sein, wenn man denselben Header mit
unterschiedlichen #defines nochmal durchlaufen lassen mĂśchte. So gesehen
einmal fĂźr typedef, und dann nochmal zum Aufbau eines initialisierten
Arrays.

DoDi

 

[Hans-Peter Diettrich]

Stefan Reuther schrieb:

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.

Ein Compiler sollte keine solche Annahmen selbständig treffen. Wenn das
genau so erwĂźnscht ist, packt man die zusammengehĂśrenden Variablen in
eine Datenstruktur.

DoDi

 

[Reinhardt Behm]

On 12.05.2015 22: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++.

DoDi

Den habe ich verstanden. Aber unter der Haube sind Refs nur constante
Pointer. Dass man in C++ jetzt . anstatt -> schreibt ist Syntactic Sugar.

Es ging darum dass auch Pascal beim Funktionsaufruf intern Pointer
benutzt. Oder weißt Du eine Methode den Wert eines var Parameters zu
ändern, ohne seine Adresse zu kennen.

--
Reinhardt

 

[Reinhardt Behm]

On 12.05.2015 23:12, Johannes Bauer wrote:

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

Nun damit habe ich kein Problem, ich weiß von wem's kommt. Aber er hat,
ohne es zu mekrn, sein eigenes Unverständnis dargelegt.

--
Reinhardt

 

[Sieghard Schicktanz]

Hallo Stefan,

Du schriebst am Tue, 12 May 2015 18:51:37 +0200:

[Interface-Defintionen]
> Der Unterschied zwischen C und den Borlandschen Pascals ist an der

Aber auch ISO-Pascal, Ada u.ä.

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).

Ja.

Mit dem Ergebnis, dass man die Schnittstellenbeschreibung immer schĂśn
manuell schreiben muss, wenn man ein Objectfile weitergeben will. Java

Kommt drauf an, fĂźr _wen_ die Schnittstellenbeschreibung gedacht ist. Der
Compiler kriegt die im Objekt mitgeliefert, wenn Du eine solche als Teil der
Dokumentation meinst - was hindert den Implementor, einfach den interface-
Teil aus der Quellendatei herauszukopieren?

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.

Letzteres ist bei den Pascal-artigen Sprachen, die hier angesprochen
wurden, mindestens genauso der Fall.

[Header-Dateien sehr gut zur Dokumentation]

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

Und was hat das mit der Dokumentation zu tun?

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

 

[Reinhardt Behm]

Sieghard Schicktanz wrote:

Hallo Stefan,

Du schriebst am Tue, 12 May 2015 18:51:37 +0200:

[Interface-Defintionen]
Der Unterschied zwischen C und den Borlandschen Pascals ist an der

Aber auch ISO-Pascal, Ada u.ä.

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).

Ja.

Mit dem Ergebnis, dass man die Schnittstellenbeschreibung immer schĂśn
manuell schreiben muss, wenn man ein Objectfile weitergeben will. Java

Kommt drauf an, fĂźr _wen_ die Schnittstellenbeschreibung gedacht ist. Der
Compiler kriegt die im Objekt mitgeliefert, wenn Du eine solche als Teil
der Dokumentation meinst - was hindert den Implementor, einfach den
interface- Teil aus der Quellendatei herauszukopieren?

Aha, und das ist weniger Arbeit, als gleich zwei Dateien (.c und .h) zu
erzeugen.

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.

Letzteres ist bei den Pascal-artigen Sprachen, die hier angesprochen
wurden, mindestens genauso der Fall.

[Header-Dateien sehr gut zur Dokumentation]
Perl unterscheidet sich hier u.a. dadurch von C/Pascal/Java, dass es da
keine Objectfiles gibt.

Und was hat das mit der Dokumentation zu tun?

--
Reinhardt

 

[Reinhardt Behm]

On 13.05.2015 18:47, Hans-Peter Diettrich wrote:

Reinhardt Behm schrieb:
On 12.05.2015 22:40, Hans-Peter Diettrich wrote:

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

Den habe ich verstanden. Aber unter der Haube sind Refs nur constante
Pointer. Dass man in C++ jetzt . anstatt -> schreibt ist Syntactic Sugar.

Sieh's mal andersrum. Pointer sind Referenzen, mit denen auch gerechnet
werden kann. Und diese Pointer-Arithmetik ist es, die Pointer gefährlich
macht.

DoDi

Wer damit nicht umgehen kann, sollte es halt bleiben lassen. Und wenn er
es trotzdem in C braucht, zwingt ihn keiner, damit zu auch rechnen.
Ich habe mt Pointern kein Problem und bei mir in der Küche gibt es auch
Messer, obwohl man sich damit schneiden kann.

Inzwischen hat das mit dem ursprünglichen Thema inzwischen rein gar
nichts mehr zu tun. Deine Argumente sind eigentlich nur noch an den
Haaren herbei gezogen.

--
Reinhardt

 

[MaWin]

"Ralph A. Schmid, dk5ras" <ralph@schmid.xxx> schrieb im Newsbeitrag
news:h45vkapemgv9906oq36an2eeknt2elbnol@4ax.com...

Guido Grohmann <guido.grohmann@gmx.de> wrote:

Faß dich doch an deine eigene Nase!

Wenn er mal doch nicht recht hat und das offenkundig wird, dann
antwortet er einfach nimmer. BTST.

Guido. Stimmt. Siehe diesen Thread.

--
MaWin, Manfred Winterhoff, mawin at gmx dot net

 

[Ralph A. Schmid, dk5ras]

"MaWin" <me@private.net> wrote:

Wenn er mal doch nicht recht hat und das offenkundig wird, dann
antwortet er einfach nimmer. BTST.

Guido. Stimmt. Siehe diesen Thread.

Ich bin jetzt zu faul, den thread herzusuchen...


-ras

--
Ralph A. Schmid
http://www.schmid.xxx/ http://www.db0fue.de/
http://www.bclog.de/ http://www.kabuliyan.de/

 

[Hans-Peter Diettrich]

Reinhardt Behm schrieb:

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

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

Den habe ich verstanden. Aber unter der Haube sind Refs nur constante
Pointer. Dass man in C++ jetzt . anstatt -> schreibt ist Syntactic Sugar.

Sieh's mal andersrum. Pointer sind Referenzen, mit denen auch gerechnet
werden kann. Und diese Pointer-Arithmetik ist es, die Pointer gefährlich
macht.

DoDi

 

[Holger]

Hans-Peter Diettrich schrieb:

Reinhardt Behm schrieb:
On 12.05.2015 22:40, Hans-Peter Diettrich wrote:

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

Den habe ich verstanden. Aber unter der Haube sind Refs nur constante
Pointer. Dass man in C++ jetzt . anstatt -> schreibt ist Syntactic Sugar.

Sieh's mal andersrum. Pointer sind Referenzen, mit denen auch gerechnet
werden kann. Und diese Pointer-Arithmetik ist es, die Pointer gefährlich
macht.

Ein Hoch auf die lebensgefährlichen Adressen von bösen Speicherzellen!

Holger

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

 

[Guido Grohmann]

MaWin schrieb:

"Ralph A. Schmid, dk5ras" <ralph@schmid.xxx> schrieb im Newsbeitrag
news:h45vkapemgv9906oq36an2eeknt2elbnol@4ax.com...
Guido Grohmann <guido.grohmann@gmx.de> wrote:

Faß dich doch an deine eigene Nase!

Wenn er mal doch nicht recht hat und das offenkundig wird, dann
antwortet er einfach nimmer. BTST.

Guido. Stimmt. Siehe diesen Thread

Hast aber eine ganz schön lange Leitung.

 

[MaWin]

"Guido Grohmann" <guido.grohmann@gmx.de> schrieb im Newsbeitrag
news:crh8odFeaifU1@mid.individual.net...

Guido. Stimmt. Siehe diesen Thread

Hast aber eine ganz schön lange Leitung.

Ich habe mir gedacht, ich warte mal, ob von dir noch was kommt.
Hab dann lange genug gewartet, um festzustellen, daß nichts kommt.
Wie erwartet.
--
MaWin, Manfred Winterhoff, mawin at gmx dot net
Homepage http://www.oocities.org/mwinterhoff/
dse-FAQ: http://dse-faq.elektronik-kompendium.de/

 

[Guido Grohmann]

MaWin schrieb:

"Guido Grohmann" <guido.grohmann@gmx.de> schrieb im Newsbeitrag
news:crh8odFeaifU1@mid.individual.net...

Guido. Stimmt. Siehe diesen Thread

Hast aber eine ganz schön lange Leitung.

Ich habe mir gedacht, ich warte mal, ob von dir noch was kommt.
Hab dann lange genug gewartet, um festzustellen, daß nichts kommt.
Wie erwartet.

Wie pawlowianisch. Kannst du nicht irgendwo anderen Leuten ans Bein
pinkeln?

 

[Holger]

Guido Grohmann schrieb:

MaWin schrieb:
"Guido Grohmann" <guido.grohmann@gmx.de> schrieb im Newsbeitrag
news:crh8odFeaifU1@mid.individual.net...

Guido. Stimmt. Siehe diesen Thread

Hast aber eine ganz schön lange Leitung.

Ich habe mir gedacht, ich warte mal, ob von dir noch was kommt.
Hab dann lange genug gewartet, um festzustellen, daß nichts kommt.
Wie erwartet.

Wie pawlowianisch. Kannst du nicht irgendwo anderen Leuten ans Bein
pinkeln?

Meinst du Uwe S., den Schrauber mit dem Lötkolben? Oder lieber den
Thomsonfreak, auch so ein armes TV-Lötschwein aus dem Repdata-Forum?

Holger