Mikrocontroller: "Compiler-Optimizer-Fehler" finden?

[Stefan Reuther]

Hans-Peter Diettrich wrote:

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.

Nein, ist sie nicht. Hast du die Standards Ăźberhaupt mal gelesen?

Der C-Standard schreibt konzeptuell 8 "translation phases" vor, von
denen 1-4 den Präprozessor betreffen, 5-7 den Compiler und 8 den Linker.
Lediglich fĂźr die AusfĂźhrung von Pragmas durch den Compiler (konzeptuell
in Phase 4) wird ein gesonderter, undefinierter Mechanismus benĂśtigt.

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.

Mit welchem MSVC hast du das probiert? Vor 20 Jahren, als der noch nicht
mal MSVC hieß?

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.

Der Präprozessor kann die #pragma-Anweisungen einfach stehenlassen und
an den Compiler weitergeben. So hat das gcc vor 20 Jahren schon gemacht.
Oder er ersetzt sie durch _Pragma-Anweisungen.


Stefan

 

[Stefan Reuther]

Hans-Peter Diettrich wrote:

Stefan Reuther schrieb:
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 ;-)

Das ist vollkommen egal fĂźr die Tatsache, dass dein "der Compiler macht
alles vollautomatisch" sich ratz-fatz ins Gegenteil verkehrt, wenn der
tolle Automatismus gegen die Wand läuft. Was er erwiesenermaßen tut.

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

Dann hättest du dir die Hilfeseite durchlesen, die Variablen CC und
CFLAGS einstellen, und weitermachen kĂśnnen. Wenn du mehr als schimpfen
gewollt hättest.

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.

Diese Sätze sind zwar syntaktisch korrekt, semantisch aber Unsinn.

Ja, jede Portierung auf andere Plattformen hat ihre Haken und Ösen. Die
meisten Portierungen erfordern Anpassungen auf Quelltext-Ebene. Der
Zielprozessor wird aber nicht plötzlich big-endian, bloß weil ich einen
Crosscompiler verwende.

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

Wir waren bei autoconf. Wenn ich ein 32-bpp-Bitmap-Bild habe, befindet
sich die Farbkomponente "rot" je nach Bytesex im oberen oder unteren
Teil eines 32-Bit-Wortes, die Alpha-Komponente jeweils am anderen Ende.

Der Algorithmus "ein Bild Ăźber ein anderes blenden" wird also je nach
Bytesex anders aussehen (und dazu fragt man autoconf), wenn er effizient
sein soll.

Ineffizient aber portabel (und ohne Forderung nach autoconf) ist, sich
die Pixelwerte aus einzelnen Bytes zusammenzustoppeln oder meinetwegen
'ntoh' zu benutzen.

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.

Gleiches gilt fĂźr *.tpu's. Den Compiler merkt nicht, dass die *.tpu mit
anderen Makro-Einstellungen als den aktuellen gebaut wurde.


Stefan

 

[Hans-Peter Diettrich]

Stefan Reuther schrieb:

Hans-Peter Diettrich wrote:

Wir waren bei autoconf. Wenn ich ein 32-bpp-Bitmap-Bild habe, befindet
sich die Farbkomponente "rot" je nach Bytesex im oberen oder unteren
Teil eines 32-Bit-Wortes, die Alpha-Komponente jeweils am anderen Ende.

Ja und? Die Positionierung der Elemente in einem strukturierten
Datensatz hängt nicht nur vom Bytesex ab. Wer auf mehrere Elemente
gleichzeitig zugreifen möchte, muß eben wissen, was er tut.

Der Algorithmus "ein Bild Ăźber ein anderes blenden" wird also je nach
Bytesex anders aussehen (und dazu fragt man autoconf), wenn er effizient
sein soll.

Und nochmal anders, wenn die Farbanteile nicht 8 Bit groß sind, oder die
Bilddateien unterschiedlichen Bytesex haben. Kann man alles
berücksichtigen, wenn man möchte, muß man aber nicht.

Wenn Du die Feinheiten der Bildverarbeitung diskutieren mĂśchtest, dann
bitte in einer dafßr zuständigen Gruppe.

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.

Gleiches gilt fĂźr *.tpu's. Den Compiler merkt nicht, dass die *.tpu mit
anderen Makro-Einstellungen als den aktuellen gebaut wurde.

Wenn Du Fehler in bestimmten Compilern diskutieren mĂśchtest, bist Du
hier auch in der falschen Gruppe. Ein BOM wĂźrde dazu sagen:

Zeige mir den Fehler, den Du haben mĂśchtest, und ich zeige Dir den dazu
passenden Compiler.

DoDi

 

[Sieghard Schicktanz]

Hallo Michael,

Du schriebst am 9 May 2015 12:59:23 GMT:

Ja, aber die Datei muß deswegen trotzdem _gelesen_ werden, d.h. der
....
Du lieferst die Gegenargumente direkt mit - die Datei muß *nicht* mehrfach
eingelesen werden.

Das kommt auf die "Intelligenz" der Implementation der Zusatzfunktion an -
ohne _muß_ immer wieder gelesen werden, mit kann es nötig sein, mindestens
zweimal zu lesen oder es wird soweit ausgewertet, daß einmal reichen kann.
Das ist halt ein "Trade off" zwischen Verarbeitungsaufwand und Aufwand fĂźr
zusätzliche Auswertung im Compiler. Solche gibt es auch an vielen anderen
Stellen.

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

 

[Sieghard Schicktanz]

Hallo Hans-Peter,

Du schriebst am Sat, 09 May 2015 10:07:40 +0200:

Stimmt, zu Pascal gibt es keinen so verbindlichen (allgemein
anerkannten) Sprach-Standard wie fĂźr C.

Im Prinzip schon - ISO-Pascal. Der relevante Punkt dabei ist weder
"verbindlich" noch "allgemein anerkannt", sondern "weit [genug] verbreitet".

Erst neulich habe ich festgestellt, daß schon D5 Aufrufe von leeren
Unterprogrammen wegoptimiert. Das sollte eigentlich jeder Compiler

Das dĂźrfte inzwischen normal sein. Was C dagegen immer noch fehlt (und
was jetzt so langsam eingefĂźhrt wird) ist das selektive Einbinden von
Unterprogrammen aus Bibliotheken und Objekt-Dateien. Da gilt immer noch
"alles oder nichts", so wie am StĂźck compiliert wird's eingebaut.

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

 

[Rainer Knaepper]

guido.grohmann@gmx.de (Guido Grohmann) am 08.05.15:

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.

Eine Frage der Perspektive. Der Umkehrschluß, dass jeder, der reich
ist, dumm oder ein Arschloch oder gar beides ist, funktioniert ja
nicht.

Rainer

--
Junge, Du bist wirklich lern- und begriffsresistent. Man kann Dir
Quellen anbieten, aus denen Du Deine Defizite abbauen könntest,
wie man will, es ist, als ob man einen Ochsen ins Ohr zwickt.
(Paul Zeiler in de.comp.hardware.kuehlung+laermdaemmung)

 

[Wolfgang Kynast]

On Sat, 9 May 2015 21:23:52 +0200, "Sieghard Schicktanz" posted:

Hallo Hans-Peter,

Du schriebst am Sat, 09 May 2015 10:07:40 +0200:

Stimmt, zu Pascal gibt es keinen so verbindlichen (allgemein
anerkannten) Sprach-Standard wie für C.

Im Prinzip schon - ISO-Pascal. Der relevante Punkt dabei ist weder
"verbindlich" noch "allgemein anerkannt", sondern "weit [genug] verbreitet".

Erst neulich habe ich festgestellt, daß schon D5 Aufrufe von leeren
Unterprogrammen wegoptimiert. Das sollte eigentlich jeder Compiler

Das dürfte inzwischen normal sein. Was C dagegen immer noch fehlt (und
was jetzt so langsam eingeführt wird) ist das selektive Einbinden von
Unterprogrammen aus Bibliotheken und Objekt-Dateien. Da gilt immer noch
"alles oder nichts", so wie am Stück compiliert wird's eingebaut.

Das ist eine Frage des Linkers und hat mit der Sprache C genau
garnichts zu tun.

--
Schöne Grüße,
Wolfgang

 

[Bernd Laengerich]

Am 09.05.2015 um 22:38 schrieb Wolfgang Kynast:

Das ist eine Frage des Linkers und hat mit der Sprache C genau
garnichts zu tun.

Nun komm doch nicht mit Fakten, wenn es eine einfache Polemik auch täte

Ach ja, ich habe damals auch mal eine einfache Mikroprozessoraufgabe der
FH für den 8085 aus Spaß mit Pascal gelöst. Wenige Ausgaben vorher stand
in der mc nämlich ein Artikel drin wie man da herumtrickst um mit
Turbo-Pascal unter CP/M 2.2 den Code mit eigener Initialisierung
auszustatten. Passte gerade wegen der ganzen Pascal-Runtime in das
größte EPROM rein den das Board vertrug. Waren effektiv wenige
Assemblerzeilen die ich dann auch eingereicht habe, das
Pascal-Experiment war lustig aber ohne praktische Belange.

Bernd

 

[Michael Schwingen]

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

Hallo Michael,

Du schriebst am 9 May 2015 12:59:23 GMT:

Ja, aber die Datei muß deswegen trotzdem _gelesen_ werden, d.h. der
...
Du lieferst die Gegenargumente direkt mit - die Datei muß *nicht* mehrfach
eingelesen werden.

Das kommt auf die "Intelligenz" der Implementation der Zusatzfunktion an -
ohne _muß_ immer wieder gelesen werden, mit kann es nötig sein, mindestens
zweimal zu lesen oder es wird soweit ausgewertet, daß einmal reichen kann.
Das ist halt ein "Trade off" zwischen Verarbeitungsaufwand und Aufwand für
zusätzliche Auswertung im Compiler. Solche gibt es auch an vielen anderen
Stellen.

Sag' ich doch. Damit ist die Aussage, daß die Datei mehrfach eingelesen
werden *muss*, definitiv falsch - ich weiß nicht, wieso Du so darauf
herumreitest, wenn Du selber zugibst, daß das so allgemein eben nicht
stimmt.

Wie gesagt: das ist trotzdem irrelevant, solange "100k Datei lesen" nicht
spürbar Zeit kostet. Das mag für denjenigen, der einen Compiler baut,
interessant sein, für eine allgemeine Bewertung der Sprache an sich ist das
Nebensache.

cu
Michael

 

[Michael Schwingen]

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

Das dürfte inzwischen normal sein. Was C dagegen immer noch fehlt (und
was jetzt so langsam eingeführt wird) ist das selektive Einbinden von
Unterprogrammen aus Bibliotheken und Objekt-Dateien. Da gilt immer noch
"alles oder nichts", so wie am Stück compiliert wird's eingebaut.

Ähm - "jetzt langsam"?

Die entsprechenden Optionen sind gefühlt seit Ewigkeiten im gcc/ld 'drin
(ich finde Treffer von vor 5 Jahren, aber ich meine, ich hätte die schon
deutlich früher benutzt - eine schnelle Suche scheint zu bestätigen, daß das
in gcc 3.2 schon 'drin war).

Aber: auch das ist eine Fähigkeit des jeweiligen Compilers/Linkers und hat
mit der Sprache an sich überhaupt nichts zu tun.

cu
Michael

 

[Sieghard Schicktanz]

Hallo Michael,

Du schriebst am 9 May 2015 22:35:11 GMT:

was jetzt so langsam eingefĂźhrt wird) ist das selektive Einbinden von
Unterprogrammen aus Bibliotheken und Objekt-Dateien. Da gilt immer noch
....
Die entsprechenden Optionen sind gefĂźhlt seit Ewigkeiten im gcc/ld 'drin

Selektives Einbinden _einzelner_ Funktionen aus Objekten?
Das Einbinden einzelner Objekte (Kompilat einer Quellendatei, die durchaus
_mehrere_ Funktionen enthalten kann und meist auch enthält) ist schon
gegeben, aber die Extraktion _nur_ der benutzten Funktionen daraus ist -
AFAIK immer noch - nicht Ăźblich.

Aber: auch das ist eine Fähigkeit des jeweiligen Compilers/Linkers und hat
mit der Sprache an sich Ăźberhaupt nichts zu tun.

Laut Kommentaren hier ist der Linker ein Bestandteil des C-Compilers.
NatĂźrlich ist der _Linker_ nicht mehr mit der Umsetzung des Quellentextes
befasst. Er hat die standardgemäß separat kompilierten Einheiten zu einem
lauffähigen Programm zusammenzufassen.

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

 

[Sieghard Schicktanz]

Hallo Michael,

Du schriebst am 9 May 2015 22:24:28 GMT:

[C-Header lesen]

Sag' ich doch. Damit ist die Aussage, daß die Datei mehrfach eingelesen
werden *muss*, definitiv falsch - ich weiß nicht, wieso Du so darauf

"Definitv" gemäß Standard muß an der Stelle der "#include"-Anweisung der
Inhalt der referenzierten Datei eingefĂźgt werden.

> herumreitest, wenn Du selber zugibst, daß das so allgemein eben nicht

Tu _ich_ das? Na, lassen wir _die_ Diskussion lieber mal.
Die Notwendigkeit fĂźr die Verarbeitung des Dateiinhalts - und was als
"Inhalt" angesehen wird, ist unterschiedlich interpretierbar - ist eben
festgeschrieben.
Daß ein Compiler (-Präprozessor) schon sofort feststellt, welchen für die
Weitergabe notwendigen "Inhalt" die Datei hat und sich z.B. "merkt", daß da
(und im betrachteten Fall sogar erst beim _wiederholten_ Verarbeiten) nichts
herauskommt, hat etwa dieselbe "Qualität" wie z.B. der Verzicht auf eine
Kreditprüfung durch eine Bank bei einem "bekannten Unternehmen": man "weiß
aus Erfahrung", daß das so ist.

Wie gesagt: das ist trotzdem irrelevant, solange "100k Datei lesen" nicht
spĂźrbar Zeit kostet. Das mag fĂźr denjenigen, der einen Compiler baut,

Es kostet im Einzelfall vielleicht keine merkbare Zeit, bei tausenden von
Vorgängen dann aber doch merklich bis unangnehm. Aber da kommt dann eben
die immer schnellere und leistungsfähigere Hardware zu Hilfe...

interessant sein, fĂźr eine allgemeine Bewertung der Sprache an sich ist
das Nebensache.

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.

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

 

[MaWin]

"Guido Grohmann" <guido.grohmann@gmx.de> schrieb im Newsbeitrag
news:cr492sF4cheU1@mid.individual.net...
all2001@spambog.com (Wolfgang Allinger) schrieb:

> Der Typ ist anscheinend schon immer so drauf.

Ja. Auch du hast merken müssen, daß man im Usenet nicht ständig
beliebigen Stuss von sich geben kann, sondern damit rechnen muss,
daß da jemand kommt, der in aller Öffentlichkeit deine Fehler
aufzeigt.

Leider hast du daraus nicht gelernt, sondern gibt immer noch
beliebigen Stuss von dir, wie man in diesem Forum erleben kann,
und versuchst stattdessen den Überbringer der schlechten Nachricht
runterzumachen. Ganz blöd Guido, ganz dumm.
--
MaWin, Manfred Winterhoff, mawin at gmx dot net
Homepage http://www.oocities.org/mwinterhoff/
dse-FAQ: http://dse-faq.elektronik-kompendium.de/

 

[Johannes Bauer]

On 10.05.2015 02:42, Sieghard Schicktanz wrote:

Die entsprechenden Optionen sind gefĂźhlt seit Ewigkeiten im gcc/ld 'drin

Selektives Einbinden _einzelner_ Funktionen aus Objekten?

Ja.

Das Einbinden einzelner Objekte (Kompilat einer Quellendatei, die durchaus
_mehrere_ Funktionen enthalten kann und meist auch enthält) ist schon
gegeben, aber die Extraktion _nur_ der benutzten Funktionen daraus ist -
AFAIK immer noch - nicht Ăźblich.

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

Aber: auch das ist eine Fähigkeit des jeweiligen Compilers/Linkers und hat
mit der Sprache an sich Ăźberhaupt nichts zu tun.

Laut Kommentaren hier ist der Linker ein Bestandteil des C-Compilers.

Linker und Compiler sind getrennte Teile mit getrennten Aufgaben. Wer
hat behauptet, dass die dasselbe sind?

NatĂźrlich ist der _Linker_ nicht mehr mit der Umsetzung des Quellentextes
befasst. Er hat die standardgemäß separat kompilierten Einheiten zu einem
lauffähigen Programm zusammenzufassen.

Der Standard beschäftigt sich nicht damit, wie der Linker bestimmte
Objekte genau zusammenfasst. Und dass, wie du beschrieben, frĂźher Linker
auf Modulebene (Objekt-Files) aus Bibliotheken diejenigen Objekte
genommen haben, die sie eben brauchen, ist deren Entscheidung. Ein
Linker, der einfach strunzdumm alle Objekte aus einer statischen Library
mit einbindet, ist immernoch standardkonform.

Man sollte schon sauber zwischen einer *Sprache* und deren
*Implementierung* differenzieren.

Es ist auch Ăźberhaupt kein Feature der *Sprache* Pascal, dass die GUI es
dem Benutzer einfach macht, die Quelldateien einzusammeln. Das ist
lediglich das GerĂźst, das jemand um eine Sprache gebaut hat und vĂśllig
unabhängig von der darunterliegenden Sprache.

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>

 

[Hans-Peter Diettrich]

Sieghard Schicktanz schrieb:

Hallo Hans-Peter,

Du schriebst am Sat, 09 May 2015 10:07:40 +0200:

Stimmt, zu Pascal gibt es keinen so verbindlichen (allgemein
anerkannten) Sprach-Standard wie fĂźr C.

Im Prinzip schon - ISO-Pascal. Der relevante Punkt dabei ist weder
"verbindlich" noch "allgemein anerkannt", sondern "weit [genug] verbreitet".

Wenn es fĂźr gcc ein ISO-Pascal Frontend gibt, reicht das fĂźr eine
"genĂźgend weite" Verbreitung aus?

Erst neulich habe ich festgestellt, daß schon D5 Aufrufe von leeren
Unterprogrammen wegoptimiert. Das sollte eigentlich jeder Compiler

Das dĂźrfte inzwischen normal sein. Was C dagegen immer noch fehlt (und
was jetzt so langsam eingefĂźhrt wird) ist das selektive Einbinden von
Unterprogrammen aus Bibliotheken und Objekt-Dateien. Da gilt immer noch
"alles oder nichts", so wie am StĂźck compiliert wird's eingebaut.

Das hat jetzt mit der Sprache nichts zu tun, sondern mit dem Linker.

DoDi

 

[Hans-Peter Diettrich]

Bernd Laengerich schrieb:

Am 09.05.2015 um 22:38 schrieb Wolfgang Kynast:

Das ist eine Frage des Linkers und hat mit der Sprache C genau
garnichts zu tun.

Nun komm doch nicht mit Fakten, wenn es eine einfache Polemik auch täte

Ach ja, ich habe damals auch mal eine einfache Mikroprozessoraufgabe der
FH für den 8085 aus Spaß mit Pascal gelöst. Wenige Ausgaben vorher stand
in der mc nämlich ein Artikel drin wie man da herumtrickst um mit
Turbo-Pascal unter CP/M 2.2 den Code mit eigener Initialisierung
auszustatten. Passte gerade wegen der ganzen Pascal-Runtime in das
größte EPROM rein den das Board vertrug. Waren effektiv wenige
Assemblerzeilen die ich dann auch eingereicht habe, das
Pascal-Experiment war lustig aber ohne praktische Belange.

Zum AIM-65 (6502) gab es ein Instant-Pascal im ROM. AFAIR waren das
gerade mal 8 KB, einschließlich Editor.

DoDi

 

[Stefan Reuther]

Sieghard Schicktanz wrote:

Du schriebst am 9 May 2015 22:35:11 GMT:
was jetzt so langsam eingefĂźhrt wird) ist das selektive Einbinden von
Unterprogrammen aus Bibliotheken und Objekt-Dateien. Da gilt immer noch
...
Die entsprechenden Optionen sind gefĂźhlt seit Ewigkeiten im gcc/ld 'drin

Selektives Einbinden _einzelner_ Funktionen aus Objekten?

Ja.

Ich habe das vor zehn Jahren in einem kommerziellen Compiler das erste
Mal benutzt. Damals war das beim gcc auch schon nicht mehr ganz neu,
aber noch irgendwie experimentell. Inzwischen setzen wir es routinemäßig
mit einer gcc-basierten Toolchain ein.

Aber: auch das ist eine Fähigkeit des jeweiligen Compilers/Linkers und hat
mit der Sprache an sich Ăźberhaupt nichts zu tun.

Laut Kommentaren hier ist der Linker ein Bestandteil des C-Compilers.
NatĂźrlich ist der _Linker_ nicht mehr mit der Umsetzung des Quellentextes
befasst. Er hat die standardgemäß separat kompilierten Einheiten zu einem
lauffähigen Programm zusammenzufassen.

Bestandteil einer C-Implementierung ist ein Tool, das in etwa das tut,
was typische Linker halt so tun. Manche davon kĂśnnen halt funktions-
granular linken, manche nicht.

Und bei Pascal ist das nicht anders. Gewisse populäre Pascal-Toolchains
kĂśnnen es halt (Turbo Pascal konnte das 1990 schon, weil sie halt ein
mit dem Rest der Welt inkompatibles Objektdateiformat hatten, dafĂźr
konnten eben frĂźhere Versionen Ăźberhaupt keine Modularisierung), andere
nicht.


Stefan

 

[Stefan Reuther]

Hans-Peter Diettrich wrote:

Stefan Reuther schrieb:
Wir waren bei autoconf. Wenn ich ein 32-bpp-Bitmap-Bild habe, befindet
sich die Farbkomponente "rot" je nach Bytesex im oberen oder unteren
Teil eines 32-Bit-Wortes, die Alpha-Komponente jeweils am anderen Ende.

Ja und? Die Positionierung der Elemente in einem strukturierten
Datensatz hängt nicht nur vom Bytesex ab. Wer auf mehrere Elemente
gleichzeitig zugreifen möchte, muß eben wissen, was er tut.

....und dieses Wissen, ob und wie er das tut, erhält er von z.B.
autoconf. q.e.d.

Der Algorithmus "ein Bild Ăźber ein anderes blenden" wird also je nach
Bytesex anders aussehen (und dazu fragt man autoconf), wenn er effizient
sein soll.

Und nochmal anders, wenn die Farbanteile nicht 8 Bit groß sind, oder die
Bilddateien unterschiedlichen Bytesex haben. Kann man alles
berücksichtigen, wenn man möchte, muß man aber nicht.

Wenn Du die Feinheiten der Bildverarbeitung diskutieren mĂśchtest, dann
bitte in einer dafßr zuständigen Gruppe.

Du hast angefangen mit einem off-topicnen "C ist scheiße, weil bei mir
autoconf mal gegen die Wand gerannt ist und ich das Problem nicht
verstanden hab". Also wĂźrg jetzt nicht ab.

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.

Gleiches gilt fĂźr *.tpu's. Den Compiler merkt nicht, dass die *.tpu mit
anderen Makro-Einstellungen als den aktuellen gebaut wurde.

Wenn Du Fehler in bestimmten Compilern diskutieren mĂśchtest, bist Du
hier auch in der falschen Gruppe. Ein BOM wĂźrde dazu sagen:

Zeige mir den Fehler, den Du haben mĂśchtest, und ich zeige Dir den dazu
passenden Compiler.

Dann versuch halt nicht ständig, C als grausiges Mittelalter und Pascal
als leuchtende Zukunft darzustellen. Sie nehmen sich nix.


Stefan

 

[Johannes Bauer]

On 10.05.2015 11:14, Sieghard Schicktanz wrote:

Wie gesagt: das ist trotzdem irrelevant, solange "100k Datei lesen" nicht
spĂźrbar Zeit kostet. Das mag fĂźr denjenigen, der einen Compiler baut,

Es kostet im Einzelfall vielleicht keine merkbare Zeit, bei tausenden von
Vorgängen dann aber doch merklich bis unangnehm. Aber da kommt dann eben
die immer schnellere und leistungsfähigere Hardware zu Hilfe...

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
man keine schnellere und leistungsfähigere Hardware, das ist kompletter
Nonsense.

Wenn das Ziel sein soll, bestimmte Dateien nur einmalig einzulegsen,
muss *jede* Programmiersprache irgendeinen Mechanismus bereitstellen, um
das zu leisten. C hat halt die (zugegebenermaßen hässlichen)
Includeguards. Die sind zwar nicht ästhetisch ansprechend, aber
sicherlich nicht das Performance-Problem das du hier beschreibst.

interessant sein, fĂźr eine allgemeine Bewertung der Sprache an sich ist
das Nebensache.

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
Includeguards realisiert wurde? Spannend. Da wüßte ich gern mehr drüber.

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>

 

[Johannes Bauer]

On 10.05.2015 12:12, Hans-Peter Diettrich wrote:

Im Prinzip schon - ISO-Pascal. Der relevante Punkt dabei ist weder
"verbindlich" noch "allgemein anerkannt", sondern "weit [genug]
verbreitet".

Wenn es fĂźr gcc ein ISO-Pascal Frontend gibt, reicht das fĂźr eine
"genĂźgend weite" Verbreitung aus?

FĂźr LLVM gibt es ein Brainfuck-Frontend.

Reicht das fĂźr "genĂźgend weite" Verbreitung aus? Ist Brainfuck jetzt
also eine weit verbreitete Sprache?

Natßrlich nicht. Muss man dir jetzt sogar noch erklären, was
"Verbreitung" bedeuted?

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>