Mikrocontroller: "Compiler-Optimizer-Fehler" finden?

[Michael Baeuerle]

Hans-Peter Diettrich wrote:

Stefan Reuther schrieb:

Egal ob inline oder nicht, ein handprogrammiertes 'ntoh' holt sich vier
einzelne Bytes mit vier Maschineninstruktionen aus dem Speicher, shiftet
und addiert sie mit drei bis sechs weiteren Instruktionen und verbrät
dazu zwei bis vier Register.

Ich weiß nicht, wieso Du hier ständig mit shift und add argumentierst.
Klar, damit *kann* man die Bytes vertauschen, doch wieviele Befehle und
Register der Compiler dafür verbrät, sieht man dem Code nicht an. Wenn
der Prozessor SWAP als Maschinenbefehl unterstützt, oder sogar die
Umwandlung größerer Dateneinheiten, dann läuft das jedenfalls deutlich
effizienter als alles, was ein Programmierer in C auscodieren kann.
Bleibt man bei 'ntoh', dann kann der Compiler den jeweils besten
Maschinencode erzeugen, auch für Maschinen, die der Programmierer
garnicht kennt.

Erfahrungsgemäß leiden Programme, in denen solche Mikro-Optimierungen
vorgenommen wurden, an ganz anderen Schwächen, die der Programmierer
überhaupt nicht im Griff hatte - und völlig unabhängig von der
benutzten Programmiersprache :-(

Da fragt man sich nur, warum gängige auf Performance optimierte Software
(OpenSSL, libjpeg-turbo, Video-Codecs aller Art, etc.) teilweise in
Assembler geschrieben ist. Wenn die Compiler so toll wären, dass sie das
alles viel besser können, dann würde man sich diesen Aufwand ganz sicher
sparen.
Naheliegende Begründung: Sie sind es nicht.

 

[Wolfgang Allinger]

On 08 May 15 at group /de/sci/electronics in article mihte1$7ib$1@news.albasani.net
<me@private.net> (MaWin) wrote:

"Wolfgang Allinger" <all2001@spambog.com> schrieb im Newsbeitrag
newsGPDP9uzQoB@allinger-307049.user.uni-berlin...

Wurde es auch nicht, sondern in C und Assembler.
Nö, in Basic und Assembler. Jedenfalls am Anfang.

Unsinn, kein Basic,
dazu reicht ein Blick in die Sourcen um das zu widerlegen.

Ah ja, und Du hast den Durchblick und Einblick, ganz besonders in die
Sources.

Bill Gates war das grösste Basic Genie der Welt!
Glaubt er noch bis heute.

Nun, wenn du nur halbwegs so klug gewesen wärest,
hättest du ja die aufkommende Microprozessorenära
mit BASIC Interpretern versorgen können.

Aber statt Milliardär bist du nun Jammerer und Troll.

Und Du outest Dich als ein Arschloch!

Oder was gibt es für einen Grund, mich persönlich anzugreifen?



Saludos (an alle Vernünftigen, Rest sh. sig)
Wolfgang

--
Wolfgang Allinger, anerkannter Trollallergiker reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung!
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot

 

[Michael Baeuerle]

Hans-Peter Diettrich wrote:

[...] Und nachdem ich
auf ADA aufmerksam gemacht wurde, das für den avr-gcc bereits verfügbar
ist, werde ich mich eher damit beschäftigen.

Für 8bit CPUs tut schon der Bloat von C++ richtig weh. Über avr-gcc mit
der avr-libc liest sich das z.B. so:
<http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_cplusplus>
Zu GNAT kann ich nichts sagen, aber zumindest bei den moderneren ADA-
Varianten würde ich mit ähnlichen Problemen rechnen.

 

[Johannes Bauer]

On 08.05.2015 12:36, Wolfgang Allinger wrote:

Wurde es auch nicht, sondern in C und Assembler.
Nö, in Basic und Assembler. Jedenfalls am Anfang.

Unsinn, kein Basic,
dazu reicht ein Blick in die Sourcen um das zu widerlegen.

Ah ja, und Du hast den Durchblick und Einblick, ganz besonders in die
Sources.

Ja. Die sind nämlich öffentlich. Gerade mal in die MS-DOS 2.0 Sources
reingeschaut:

[~/tmp/dos/msdos/v20source]: ls -1 | awk -F '.' '{print $2}' | sort |
uniq -c | sort -n
1 BAS
1 HLP
2
2 OVR
12 txt
100 ASM

Also überwiegend Assembler.

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>

 

[Guido Grohmann]

MaWin schrieb:

Nun, wenn du nur halbwegs so klug gewesen wärest,
hättest du ja die aufkommende Microprozessorenära
mit BASIC Interpretern versorgen können.

klug != geschäftstüchtig.

Guido

 

[Guido Grohmann]

all2001@spambog.com (Wolfgang Allinger) schrieb:

> Und Du outest Dich als ein Arschloch!

https://www.youtube.com/watch?v=21EjrKjqg5k



scnr Guido

 

[Wolfgang Allinger]

On 08 May 15 at group /de/sci/electronics in article mii992$shl$1@news.albasani.net
<dfnsonfsduifb@gmx.de> (Johannes Bauer) wrote:

On 08.05.2015 12:36, Wolfgang Allinger wrote:

Wurde es auch nicht, sondern in C und Assembler.
Nö, in Basic und Assembler. Jedenfalls am Anfang.

Unsinn, kein Basic,
dazu reicht ein Blick in die Sourcen um das zu widerlegen.

Ah ja, und Du hast den Durchblick und Einblick, ganz besonders in
die Sources.

Ja. Die sind nämlich öffentlich. Gerade mal in die MS-DOS 2.0 Sources
reingeschaut:

[~/tmp/dos/msdos/v20source]: ls -1 | awk -F '.' '{print $2}' | sort |
uniq -c | sort -n
1 BAS
1 HLP
2
2 OVR
12 txt
100 ASM

Also überwiegend Assembler.

Schön, aber es ging um Windoof, nicht um DOS.



Saludos (an alle Vernünftigen, Rest sh. sig)
Wolfgang

--
Wolfgang Allinger, anerkannter Trollallergiker reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung!
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot

 

[Wolfgang Allinger]

On 08 May 15 at group /de/sci/electronics in article cr3q0gFdqhU1@mid.individual.net
<guido.grohmann@gmx.de> (Guido Grohmann) wrote:

all2001@spambog.com (Wolfgang Allinger) schrieb:

Und Du outest Dich als ein Arschloch!

https://www.youtube.com/watch?v=21EjrKjqg5k



scnr Guido

Ja danke, ich verstehe: MaWin MajorArschloch Winterhoff.

Ist das dann offiziell und amtlich, dass dieser Major mich anpissen
darf? :]

Ich glaube nicht, Tim!




Saludos (an alle Vernünftigen, Rest sh. sig)
Wolfgang

--
Wolfgang Allinger, anerkannter Trollallergiker reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung!
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot

 

[Stefan Reuther]

Gerhard Hoffmann wrote:

Am 07.05.2015 um 15:54 schrieb Reinhardt Behm:
On 08.05.2015 00:40, Stefan Reuther wrote:
In C kann ich ja schließlich printf benutzen, nachdem ich in Assembler
den seriellen Treiber zum Laufen bekommen habe.

+1

In Embedded Systemen hat man meist auch noch zumindest soft real time
Anforderungen. Spätestens bei der Kommunikation mit anderen Geräten wird
ein Debugger ziemlich nutzlos, weil Brekapoints oder Singlestepping zu
Timeouts fĂźhrt.

Ahm ja! Und das printf() stĂśrt die Echtzeiteigenschaften natĂźrlich
in keiner Weise. Am besten in der Kernel-Version.

Ein printf() stĂśrt zumindest nicht den Heartbeat auf dem
Kommunikationslink oder lässt den FIFO im Audiotransmitter unterlaufen.
Idealerweise schreibt es in einen Puffer, den die ISR asynchron rausgibt.

Aber der Punkt ist nicht printf(), sondern die Tatsache, dass man, wenn
man eine Hochsprache hat, viel einfacher mal in die Programmlogik
eingreifen und Testinformationen abgreifen kann als wenn man nur
Assembler hat. Folglich ist man nur in Assembler zwingend auf einen
Debugger angewiesen.

Und, mal ehrlich, was die typischen heutzutage Eclipse-basierten
Hochsprachen-IDEs an Debuggern mitliefern, ist fĂźr einen, der Green
Hills oder Lauterbach kennt, unter aller Kanone. Das fragile
umständliche Zeug will man gar nicht benutzen.


Stefan

 

[Stefan Reuther]

Hans-Peter Diettrich wrote:

Stefan Reuther schrieb:
Hans-Peter Diettrich wrote:
Oder config.h und Makefile mal eben selber schreiben. BTDT.

Davor die dafĂźr notwendigen Sprachen (make, M4...) lernen:

config.h ist C. Und wer kein Buildsystem beherrscht (es muss ja nicht
mal unbedingt make sein) mĂśge sich bitte nicht "Entwickler" nennen.

Was Du Buildsystem nennst, nenne ich eine weitere Schwäche von C :-(

In Pascal reicht es erst mal, das Startmodul anzugeben, um daraus ein
lauffähiges Programm erzeugen zu lassen.

Nicht "In Pascal", sondern "bei manchen Pascal-Compilern".

Ich habe hier ein Pascal-Programm (4 MByte Sourcecode), bei dem sich der
tolle vollautomatische Compiler beim Übersetzen wegen Speichermangels
selbst zerlegt. Was hätte ich nur fßr einen Compiler gegeben, dem ich
die Quellen alle einzeln hätte vorlegen kÜnnen! (Nach tagelangem Basteln
kam dann ein Skript dabei raus, das den Compiler anlĂźgt, und ihm beim
Compilieren von Modul X nur die KĂśpfe von Y und Z vorlegt, damit er sich
nicht mit den RĂźmpfen belastet. Wie Headerfiles in C quasi.)

In Free Pascal geht das einfacher.

Und weißt du auch warum? Weil sich jemand die Mühe gemacht hat, und all
die Fallunterscheidungen, die autoconf fĂźr dich machen wĂźrde, bereits
gemacht hat.

Ist daran irgendwas zu bemängeln? Hast Du schon einmal einen Compiler
geschrieben, oder an eine neue Plattform angepaßt, für die Du ein
Programm entwickeln solltest?

Ich habe zumindest sowohl Compiler geschrieben, als auch Programme an
Plattformen angepasst.

Zugegeben, ich weiß nicht wie autoconf heute funktioniert. Zu meiner
Zeit mußte jedenfalls jedes einzelne Projekt händisch an die
Zielplattform angepaßt werden, und dazu mußte der Entwickler die Details
dieser Zielplattform selbst kennen.

Von einem nĂźtzlichen Portierungs-/CrossCompile-System wĂźrde ich deshalb
erwarten, daß so eine Anpassung nur einmal durchgeführt werden muß,

Mit Autoconf muss der Entwickler nicht die Details der Zielplattformen
kennen ("i386 ist little-endian, 68000 ist big-endian"), sondern nur die
mĂśglichen Unterscheidungen ("es gibt big und little").

Und diese Unterscheidungen kann einem auch das beste Portierungs- /
Crosscompile-System nicht abnehmen.

Egal ob inline oder nicht, ein handprogrammiertes 'ntoh' holt sich vier
einzelne Bytes mit vier Maschineninstruktionen aus dem Speicher, shiftet
und addiert sie mit drei bis sechs weiteren Instruktionen und verbrät
dazu zwei bis vier Register.

Ich weiß nicht, wieso Du hier ständig mit shift und add argumentierst.
Klar, damit *kann* man die Bytes vertauschen, doch wieviele Befehle und
Register der Compiler dafßr verbrät, sieht man dem Code nicht an. Wenn
der Prozessor SWAP als Maschinenbefehl unterstĂźtzt, oder sogar die
Umwandlung größerer Dateneinheiten, dann läuft das jedenfalls deutlich
effizienter als alles, was ein Programmierer in C auscodieren kann.
Bleibt man bei 'ntoh', dann kann der Compiler den jeweils besten
Maschinencode erzeugen, auch fĂźr Maschinen, die der Programmierer
garnicht kennt.

Erstens tun das real existierende Compiler nicht.

Zweitens ging es darum, Code zu schreiben (Krypto, Bildverarbeitung,
Audio, etc.), der gar kein 'ntoh' benutzt, denn Code, der kein 'ntoh'
benutzt ist immer effizienter als Code, der es benutzt, egal, wie
effizient es ist.

Sonst ließen sich z.B. die langen Compilezeiten etwa halbieren, wenn der
Präprozessor nicht alle bereits eingebundenen Header nochmal durchlesen
müßte. Eine neue Präprozessor-Direktive wäre da sehr hilfreich, wird
aber nach meiner Erfahrung von der C Gemeinde unbesehen abgelehnt.

Welche "eingebundenen Header nochmal durchlesen" denn bitte? Es ist
Stand der Technik seit 25 Jahren, dass der Compiler in einem
Compilerlauf ein Headerfile nur einmal liest, wenn es einen korrekten
Include-Guard hat.

Auch hier bin ich mir nicht sicher, ob Du das richtig verstanden hast.
Was unterscheidet (aus Sicht des Compilers bzw. Präprozessors) einen
korrekten von einem inkorrekten Include-Guard, und wer ist dafĂźr
zuständig, diesen in jeden einzelnen Headerfile reinzuschreiben?

Falls Du auf #include_once oder sowas anspielst, dann ist das auch
wieder eine (durchaus begrüßenswerte) Erweiterung des Präprozessors.
Andernfalls bleibt dem Präprozessor nichts weiter ßbrig, als den bereits
geĂśffneten Headerfile bis #endif durchzulesen.

Nochmal langsam zum Mithäkeln: es ist Stand der Technik seit 25 Jahren,
dass ein Compiler nach dem Einlesen eines Headerfiles feststellt, dass
das Ding einen korrekten Include-Guard hat, und es einfach nicht nochmal
öffnet, wenn es erneut angefordert wird. Er weiß ja schließlich, dass er
darin nur ein #ifndef/#define/ignoriertes Zeug/#endif finden wird.

Bevor du mir Unverständnis vorwirfst, lies einfach mal das Manual eines
20 Jahre alten gcc.

Hacks wie "precompiled headers"
sind unsicher und in anderen Sprachen nicht einmal notwendig.

"Wir kompilieren die FunktionskÜpfe in eine Binärdatei", wie das z.B.
Turbo Pascal mit seinen *.tpu's macht, ist nichts anderes als ein
"precompiled header".


Stefan

 

[Stefan Reuther]

Sieghard Schicktanz wrote:

Du schriebst am Thu, 07 May 2015 16:49:23 +0200:
Ich habe schon auf dem Amiga 500 Assembler gedebuggt, weit bevor ich
meine erste Zeile C geschrieben hatte. Debugging und "Programmieren in
C" sind zwei vĂśllig orthogonale Konzepte. Insofern ist die Aussage, dass
Debugger C zuzurechnen sind, Quatsch.

Die Entwicklung der Debugger erfolgte im Zusammenhang mit der Entwicklung
von C. Daß die ursprünglich nicht zum Erstellen von Software gedacht waren,
tut dem ja keinen Abbruch.

Das ist gequirlter Unsinn.

http://en.wikipedia.org/wiki/Dynamic_debugging_technique
"The first version of DDT was developed at MIT for the PDP-1 computer in
1961."

http://en.wikipedia.org/wiki/C_%28programming_language%29#History
"The development of C started in 1972 on the PDP-11 Unix system."


Stefan

 

[Guido Grohmann]

all2001@spambog.com (Wolfgang Allinger) schrieb:

> Ja danke, ich verstehe: MaWin MajorArschloch Winterhoff.

Der ist eher der Schütze mit eingeschränkter Treffsicherheit, wie er
regelmäßig hier unter Beweis stellt, wenn es mal um Dinge abseits der
Elektronik an sich geht.

Ist das dann offiziell und amtlich, dass dieser Major mich anpissen
darf? :]

Der Typ ist anscheinend schon immer so drauf. Das war auch das erste,
was der Herr seinerzeit mit mir gemacht hat, als ich hier in d.s.e.
aufgeschlagen bin. Und tröste dich, in einem mir bekannten Forum hat er
es auch gleich mit seinem ersten Thema bei 95% der Forenteilnehmer
verkackt. "Viel Feind - viel Ehr" scheint sein Motto zu sein.

> Ich glaube nicht, Tim!



Guido

 

[Christian Zietz]

Wolfgang Allinger schrieb:

> Schön, aber es ging um Windoof, nicht um DOS.

Auch das wurde nicht in BASIC programmiert.

Christian
--
Christian Zietz - CHZ-Soft - czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA

 

[MaWin]

"Wolfgang Allinger" <all2001@spambog.com> schrieb im Newsbeitrag
newsGTDh9JjQoB@allinger-307049.user.uni-berlin...

Ah ja, und Du hast den Durchblick und Einblick, ganz besonders in die
Sources.

Sicher hat man den als ernsthafter Softwareentwickler,
https://torrentfreak.com/microsoft-takes-pirated-windows-nt-4-0-source-code-offline-150415/

Aber statt Milliardär bist du nun Jammerer und Troll.
Und Du outest Dich als ein Arschloch!

Wenn du es bereits als Angriff ansiehst, wenn man dir die Realität
vor Augen hält, wird wohl die ganze Welt voller Arschlöcher sein.
--
MaWin, Manfred Winterhoff, mawin at gmx dot net
Homepage http://www.oocities.org/mwinterhoff/
dse-FAQ: http://dse-faq.elektronik-kompendium.de/

 

[Sieghard Schicktanz]

Hallo Michael,

Du schriebst am 8 May 2015 09:35:50 -0000:

Genau aus diesem Grund - "Include-Guard" - ist es eben _nicht_ so, daß
"der Compiler [Include-Files] in einem Compilerlauf ein Headerfile nur
einmal liest".

Doch, das ist so. Denn das wird alles vom Präprozessor gemacht. Den kann
man nun natĂźrlich als Teil des C-Compilers definieren, genau genommen
ist er das aber nicht wirklich.

Man kann den Präprozessor natßrlich auch "nicht zum C-Compiler gehÜrig"
ansehen. Tatsächlich ist er aber heute oft ein Bestandteil dessen, und ein
C-Compiler ganz ohne seinen Präprozessor ist nur ein halber solcher. Ihm
fehlen ein ganze Reihe Sprachelemente, eben alles, was nicht zur
Verarbeitung des "eigentlichen" Programms gehĂśrt, wie "manifeste
Konstanten", Makros, bedingte Kompilierung und teils sogar Kommentare,
die manchmal (oft? immer?) vom Präprozessor entfernt werden.

> Ich habe den cpp des GCC auch schon fĂźr einen non-C Compiler verwendet

Wenn er als eigenständiges Programm vorhanden ist, geht das natßrlich.

werden, wobei natĂźrlich Vereinfachungen mĂśglich sind, wenn gewisse
Direktiven
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
....
Die markierte Stelle ist entscheidend:
Mit "Include-Guard" läuft nur der Präprozessor x-mal drßber (dabei muss
er - außer beim ersten Mal - aber nur noch "#if" und"#endif" wirklich
ausfĂźhren). Der eigentliche C-Code geht nur einmal in den Compiler und
durch dessen Parser.

Ja, aber die Datei muß deswegen trotzdem _gelesen_ werden, d.h. der
Datentransfer, der wohl mehr Zeit in Anspruch nimmt als die Verarbeitung,
findet mehrmals statt.
(Außer es gibt einem Mechanismus, der "sich merkt", daß die Datei nach
durcharbeiten nur eine leere Ausgabe erzeugt und sie deshalb bei evtln.
Folgeaufrufen ignoriert.)

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

 

[Wolfgang Kynast]

On Fri, 8 May 2015 21:50:26 +0200, "Sieghard Schicktanz" posted:

Hallo Michael,

Du schriebst am 8 May 2015 09:35:50 -0000:

Genau aus diesem Grund - "Include-Guard" - ist es eben _nicht_ so, daß
"der Compiler [Include-Files] in einem Compilerlauf ein Headerfile nur
einmal liest".

Doch, das ist so. Denn das wird alles vom Präprozessor gemacht. Den kann
man nun natürlich als Teil des C-Compilers definieren, genau genommen
ist er das aber nicht wirklich.

Man kann den Präprozessor natürlich auch "nicht zum C-Compiler gehörig"
ansehen.

IIRC ist er schon in K&R definiert und gehört selbstverständlich zum
C-Compiler.

--
Schöne Grüße,
Wolfgang

 

[Hans-Peter Diettrich]

Stefan Reuther schrieb:

In Pascal reicht es erst mal, das Startmodul anzugeben, um daraus ein
lauffähiges Programm erzeugen zu lassen.

Nicht "In Pascal", sondern "bei manchen Pascal-Compilern".

Stimmt, zu Pascal gibt es keinen so verbindlichen (allgemein
anerkannten) Sprach-Standard wie fĂźr C.
Korrekterweise müßte bei *jeder* Sprache jedesmal angegeben werden,
welche Version gemeint ist - aber wer macht das schon ;-)

Ich habe hier ein Pascal-Programm (4 MByte Sourcecode), bei dem sich der
tolle vollautomatische Compiler beim Übersetzen wegen Speichermangels
selbst zerlegt.

Das kann jedem Compiler passieren, wenn seine internen Tabellen nicht
mehr in den Speicher passen. Und schlecht programmierte Compiler gibt es
doch fĂźr jede Sprache, wenn man nur lange genug danach sucht ;-)

Zugegeben, ich weiß nicht wie autoconf heute funktioniert. Zu meiner
Zeit mußte jedenfalls jedes einzelne Projekt händisch an die
Zielplattform angepaßt werden, und dazu mußte der Entwickler die Details
dieser Zielplattform selbst kennen.

Von einem nĂźtzlichen Portierungs-/CrossCompile-System wĂźrde ich deshalb
erwarten, daß so eine Anpassung nur einmal durchgeführt werden muß,

Mit Autoconf muss der Entwickler nicht die Details der Zielplattformen
kennen ("i386 ist little-endian, 68000 ist big-endian"), sondern nur die
mĂśglichen Unterscheidungen ("es gibt big und little").

Zu meiner Zeit[tm] scheiterte configure oft schon, weil der Compiler
nicht richtig aufgerufen wurde, oder unbrauchbare Annahmen Ăźber den
Namen des Compilats etc. vorkamen ("compiler cannot create
executables"). Wer daran Schuld war, konnte ich nicht feststellen, denn
jedes getestete Projekt verabschiedete sich mit anderen Fehlermeldungen.
[Damals habe ich mir Projekte gewĂźnscht, bei denen die Fehlermeldungen
vom Compiler stammen, und nicht von irgendwelchen Tools, mit denen die
Quellen erst in einen compilierbaren Zustand gebracht werden mĂźssen.]

Und diese Unterscheidungen kann einem auch das beste Portierungs- /
Crosscompile-System nicht abnehmen.

Einigen wir uns doch darauf, daß jede Portierung auf andere Plattformen
ihre Haken und Ösen hat. Der eine schwört auf Anpassung auf
Quelltext-Ebene, der andere auf Crosscompiler. Wobei die Portierung des
Compilers selbst ohne Crosscompiler garnicht geht - und der scheint mir
das wesentlichste Problem mit configure unter Windows/Cygwin zu sein.

Bleibt man bei 'ntoh', dann kann der Compiler den jeweils besten
Maschinencode erzeugen, auch fĂźr Maschinen, die der Programmierer
garnicht kennt.

Erstens tun das real existierende Compiler nicht.

Stimmt, manche machen das vÜllig selbständig, beim Lesen und Schreiben
von Dateien

Zweitens ging es darum, Code zu schreiben (Krypto, Bildverarbeitung,
Audio, etc.), der gar kein 'ntoh' benutzt, denn Code, der kein 'ntoh'
benutzt ist immer effizienter als Code, der es benutzt, egal, wie
effizient es ist.

Erst neulich habe ich festgestellt, daß schon D5 Aufrufe von leeren
Unterprogrammen wegoptimiert. Das sollte eigentlich jeder Compiler
kĂśnnen ;-)

Aber jetzt sind wir wieder bei Stilfragen. Da ich mich häufig mit
anderer Leute Code befassen muß, ist es mir viel lieber, wenn dort
einfach herauslesbar ist, *was* der Code tun soll, nicht *wie* er etwas
tut. Wenn ein Mensch oder Compiler erkennen kann, *was* der Code
bedeutet, lassen sich dort Änderungen, Erweiterungen, Fehlerkorrekturen,
Portierungen, Optimierungen usw. viel leichter durchfĂźhren, als an
hochoptimiertem (notfalls bis auf Assembler-Ebene heruntergebrochenem) Code.

Andererseits kann sich natĂźrlich ein Programmierer oder Hersteller von
Komponenten oder Bibliotheken unentbehrlich machen, indem er mĂśglichst
undurchsichtigen Code schreibt. Noch ein Grund, sowas abzulehnen.

Nochmal langsam zum Mithäkeln: es ist Stand der Technik seit 25 Jahren,
dass ein Compiler nach dem Einlesen eines Headerfiles feststellt, dass
das Ding einen korrekten Include-Guard hat, und es einfach nicht nochmal
öffnet, wenn es erneut angefordert wird. Er weiß ja schließlich, dass er
darin nur ein #ifndef/#define/ignoriertes Zeug/#endif finden wird.

Sag's doch gleich, so macht das endlich Sinn ;-)

Bevor du mir Unverständnis vorwirfst, lies einfach mal das Manual eines
20 Jahre alten gcc.

Nein, ich verkneife mir jetzt einen bissigen Kommentar ßber ältere gcc -
nach meiner ersten Kontaktaufnahme habe ich mich davon mit Entsetzen
abgewandt :-(

Hacks wie "precompiled headers"
sind unsicher und in anderen Sprachen nicht einmal notwendig.

"Wir kompilieren die FunktionskÜpfe in eine Binärdatei", wie das z.B.
Turbo Pascal mit seinen *.tpu's macht, ist nichts anderes als ein
"precompiled header".

Mit dem Unterschied, daß eingefügte Quelltext-Dateien (#include) ggf. zu
unterschiedlichen Ergebnissen fĂźhren kĂśnnen, wenn z.B. zwischendrin
Makros geändert wurden. Aber wenn das tatsächlich ein erwßnschter Effekt
ist, darf so eine Datei natĂźrlich auch keinen Guard enthalten.


Danke fĂźr das Update Ăźber den Stand der Technik bzgl. Headerfiles.
Zumindest nach Nachhaken kamen dann doch noch Informationen rĂźber, die
mir in anderen Diskussionen stets vorenthalten wurden

DoDi

 

[Hans-Peter Diettrich]

Sieghard Schicktanz schrieb:

Man kann den Präprozessor natßrlich auch "nicht zum C-Compiler gehÜrig"
ansehen.

Nicht nach den neueren C Standards. Dort ist die Tokenisierung und
Verarbeitung von Präprozessor-Anweisungen, Kommentaren, Makro-Expansion
etc. untrennbar ineinander und mit dem Parser verwoben.

Mircosoft hält sich natßrlich nicht daran, und hat Konstrukte in den
Windows Headern, die nur von MSVC wunschgemäß interpretiert werden. Nach
MSVC leitet /##/ als // einen Kommentar ein, nach C98 sind das zwei /
und damit fehlerhaft.

Auch #pragma kann z.B. nur dann eine Wirkung entfalten, wenn es bis zum
Compiler gelangt. Das verbietet eindeutig die Verwendung eines
unabhängigen Präprozessors, der zur Zeit von K&R noch Standard war und
lange Zeit noch als selbständiges Tool zum Compiler mitgeliefert wurde.

DoDi

 

[Michael Baeuerle]

Wolfgang Kynast wrote:

Sieghard Schicktanz wrote:
Du schriebst am 8 May 2015 09:35:50 -0000:

Doch, das ist so. Denn das wird alles vom Präprozessor gemacht. Den kann
man nun natürlich als Teil des C-Compilers definieren, genau genommen
ist er das aber nicht wirklich.

Man kann den Präprozessor natürlich auch "nicht zum C-Compiler gehörig"
ansehen.

IIRC ist er schon in K&R definiert und gehört selbstverständlich zum
C-Compiler.

Mir ging es darum, was wie verarbeitet wird. Und da sind in den
üblichen C-Compilern mindestens drei klar getrennte Module vorhanden:
- Präprozessor
- Compiler
- Linker
Im Fall z.B. des GCC sind das auch jeweils separate Binaries, der
Präprozessor hat eine eigene man page cpp(1) und auf AIX wird vom GCC
z.B. der IBM Linker ld(1) verwendet. Beide kann man auch sinnvoll
separat verwenden (für andere Sprachen oder mit Modulen anderer
Compiler).
Auch wenn einem eine Norm erlaubt das alles als ein einzelnes Binary zu
implementieren, die Funktionsweise ändert sich dadurch nicht wirklich.
Und man kann zumindest jedem POSIX konformen "c89" und "c99" Frontend
mit "-E" bzw. "-c" befehlen, nach Durchlauf von Modul 1 bzw. 2 aufzu-
hören. Das erlaubt einem dann trotzdem den Präprozessor separat und auch
einen fremden Linker zu verwenden.


Zurück zum Thema:
Durch diese Module läuft das Programm sequentiell durch, im Falle des
"Include-Guard" belastet der nur den Präprozessor (der viel simpler ist
als der Compiler und daher auch weniger Ressourcen verbraucht). Selbst
wenn der x-mal drüber läuft, kostet das ziemlich wenig.
--
[Wunsch nach geprüfter Sicherheit] Dein Wunsch ist längst erfüllt - es
gibt genügend Buden die Dir gegen Münzeinwurf Deine IT-Sicherheit
zertifizieren. Du musst natürlich fest daran glauben dass es hilft,
sonst bringt es nichts. René Schuster in dcsm

 

[Michael Schwingen]

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

Die markierte Stelle ist entscheidend:
Mit "Include-Guard" läuft nur der Präprozessor x-mal drüber (dabei muss
er - außer beim ersten Mal - aber nur noch "#if" und"#endif" wirklich
ausführen). Der eigentliche C-Code geht nur einmal in den Compiler und
durch dessen Parser.

Ja, aber die Datei muß deswegen trotzdem _gelesen_ werden, d.h. der
Datentransfer, der wohl mehr Zeit in Anspruch nimmt als die Verarbeitung,
findet mehrmals statt.
(Außer es gibt einem Mechanismus, der "sich merkt", daß die Datei nach
durcharbeiten nur eine leere Ausgabe erzeugt und sie deshalb bei evtln.
Folgeaufrufen ignoriert.)

Du lieferst die Gegenargumente direkt mit - die Datei muß *nicht* mehrfach
eingelesen werden.

Ein Test mit strace und gcc unter Linux bestätigt das - sobald ein korrekter
include-guard vorhanden ist, wird die Datei nur *einmal* gelesen.

Das sind aber eigentlich uninteressante Implementierugs-Details: der
Präprozessor benötigt nur einen kleinen Bruchteil der gesamten Compile-Zeit,
und die Datei ist eh beim 2. Mal im Cache des Betriebssystems - wenn ein
Compilerhersteller also entscheidet, diese Optimierung nicht zu brauchen,
ist das auch OK - an anderer Stelle kann man das Ganze möglicherweise
deutlich besser beschleunigen.

cu
Michael