Mikrocontroller: "Compiler-Optimizer-Fehler" finden?

[Hans-Peter Diettrich]

Sieghard Schicktanz schrieb:

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.

Wenn der *komplette* Inhalt einer Datei mit einem "#ifndef wasauchimmer"
umgeben ist, dann kann der Präprozessor vor jedem weiteren Durchlauf mit
*Sicherheit* feststellen, ob wasauchimmer definiert ist.

DoDi

 

[Stefan Reuther]

Sieghard Schicktanz wrote:

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.

Nein, muss nicht, denn der Compiler darf tun, was ihm beliebt, solange
das Ergebnis das gleiche ist als wenn er diese Datei eingefßgt hätte.

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.

Der gcc kann seit >20 Jahren das mehrfache Einlesen von Headerfiles
vermeiden. Der Algorithmus ist dokumentiert und einfach verständlich und
kann daher guten Gewissens als praktikabel gelten. Auch, wenn einzelne
Compilerbauer den aus verschiedenen GrĂźnden nicht umsetzen kĂśnnen oder
wollen.


Stefan

 

[Bernd Laengerich]

Am 10.05.2015 um 12:19 schrieb Hans-Peter Diettrich:

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

AFAIR waren das 5 ROMs a 4kB, von denen einer direkt auf der
AIM-65-Platine und 4 auf einer Erweiterungsplatine installiert wurden.
Wieviel davon Editor, Compiler und wieviel Runtime waren weiß ich nicht.
Das sagt weiterhin nichts über den 8085-Code aus noch über die Größe des
EPROM-Bausteines den das Eval-Board vertrug (es waren 8kB IIRC).
6502-Code war i.d.R etwas kompakter als solcher für den 8080.
Das eigentliche Programm waren nur wenige zig Byte, der Rest war
"Pascal-Bloat".

Bernd

 

[Michael Schwingen]

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

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.

Du willst die Doku zu -ffunction-sections/-fdata-sections/--gc-sections
lesen, in Kombination leistet das genau das gewünschte (und hilft je nach
Projekt spürbar, die Grösse des erzeugten Binaries zu reduzieren).

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.

Und? Das bleiben Eigenschaften einer bestimmten Implementierung, egal, ob
jetzt Compiler/Linker getrennt sind oder nicht. Mit der Sprache an sich
("mit C geht das nicht") hat das überhaupt nichts zu tun.

BTW: sobald man bei gcc LTO benutzt, laufen Teile des
Optimizers/Codegenerators im Linker (bzw. danach):

https://gcc.gnu.org/wiki/LinkTimeOptimization

cu
Michael

 

[Michael Schwingen]

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

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.

Korrekt. Wenn das Tool weiß, das der Inhalt leer ist, muß die Datei dazu
*nicht* von Platte gelesen werden - das ist eine triviale Optimierung.

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.

Ja. Und es steht nirgendwo, daß der Präprozessor das nicht cachen darf, ohne
die Datei mehrfach zu lesen.

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.

Es kostet in der Praxis kaum Performance (auch auf alter Hardware!). Es gibt
eine trivial implementierbare Lösung, die in der Praxis auch eingesetzt
wird, die diesen minimalen Aufwand vermeidet - also was soll die Diskussion?
Erstens ist da kein wirkliches Problem, und zweitens ist es längst gelöst.

cu
Michael

 

[Myn Seudop]

Johannes Bauer wrote:

> Für LLVM gibt es ein Brainfuck-Frontend.

Jetzt verwirr den Armen doch nicht so. Nachher verwechselt er
Brainfuck noch mit der Arduino-IDE oder C++ und schreibt daraufhin
irgendwelchen Unsinn über C. Mit diesen Unterschieden hat es unser
Pascal-Experte ja nicht so.

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

Ich könnte nachgucken, wo sein heiliges ISO-Pascal wohl im TIOBE-
Index steht, aber ich bin zu faul.

Myn

 

[Myn Seudop]

I wrote:

Ich könnte nachgucken, wo sein heiliges ISO-Pascal wohl im TIOBE-
Index steht, aber ich bin zu faul.

Ach, weils soviel Spaß macht: Das 15 Jahre alte klassische (nicht
..NET) Visual Basic kommt dort noch vor Object Pascal (Delphi) und
reguläres Pascal wird selbst von Sprachen wie F# oder R überholt.

Myn

 

[Hans-Peter Diettrich]

Stefan Reuther schrieb:

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.

Er erhält dieses Wissen nur, wenn er *zusätzlich* weiß, wonach er fragen
muß. Keine Frage - keine Antwort :-]

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.

Wieder so eine falsche Verallgemeinerung. Mir ging es um Probleme, die
durch die Benutzung von Tools *außerhalb* des Compilers entstehen
kĂśnnen. Ob und wie sich diese Probleme lĂśsen lassen, steht dann auf
einem anderen Blatt. Mit der Sprache C hat das nur so weit zu tun, als
jemand die Beherrschung aller dazu existierenden Tools zur Voraussetzung
fßr die Erzeugung von Programmen macht. Nächste Woche kommt dann ein
weiteres Tool heraus, ohne dessen Einsatz ein fremdes Projekt nicht mehr
korrekt compilierbar ist, und schon ist die Kacke wieder am dampfen :-(
Soll ich jetzt auch noch q.e.d. dazuschreiben?

Ich hätte ja nichts dagegen, wenn autoconf, automake oder wasauchimmer
zum *Sprachstandard* von C hinzugefügt würde. Dann müßte jeder C
Compiler bzw. Toolchain auf jeder Plattform damit umgehen kĂśnnen, und
bei Problemen läge der Schwarze Peter beim Compiler-Hersteller.

DoDi

 

[Hans-Peter Diettrich]

Sieghard Schicktanz schrieb:

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

Das kann man jetzt beliebig eng oder weit sehen. Unterm Strich reicht es
aus, wenn der Compiler ein lauffähiges Programm erstellen kann, egal wie
er das macht.

Und da jeder Compiler einen Linker benĂśtigt, ist es nur effizient, wenn
er dafßr ein selbständiges sprach-unabhängiges Tool aufruft. Dann ist
der Hersteller der Plattform dafßr zuständig, die zur Programmerstellung
notwendige Toolchain bereitzustellen, die er ja selbst schon zur
Erzeugung des Systems, der Systembibliotheken und Utilities benĂśtigt.

DoDi

 

[Holger]

MaWin schrieb:

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

Usenet ist Streß mit Meinungen, die in der Regel in Beschimpfungen
abgleiten. Ich habe, ganz offen gesagt, keine Lust mehr, hier noch viel
hineinzutragen. Ich habe es ja erlebt mit meinen zwei Reparaturen und
einmal mit diesem neu aufgelegten 8-Bit-Prozessor, wie unvorstellbar
bekloppt die Leute hier reagieren.

Da noch fachliche Expertise zu verlangen, ist meines Erachtens ein Ding
der Unmöglichkeit.

Holger

 

[Johannes Bauer]

On 10.05.2015 13:55, Hans-Peter Diettrich wrote:

Ich hätte ja nichts dagegen, wenn autoconf, automake oder wasauchimmer
zum *Sprachstandard* von C hinzugefĂźgt wĂźrde.

Oh. Mein. Gott.

Mein persĂśnlicher Albtraum: Du im C-Standard-Komitee.

Das ist ja schon so schlecht, dass mir dazu gar nichts mehr einfällt.
Nicht mal satirisch kann man das noch Ăźberzeichnen, weil diser
"Vorschlag" schon *so* weit jenseits von Gut & BĂśse ist.

Auch wenn es bei dir auf taube Ohren trifft: Der C-Standard ist
*absichtlich* so geschrieben wie er ist. Das war kein Versehen und kein
Übersehen, dass da autoconf nicht mit drin gelandet ist. Jedem, der
darĂźber auch nur 30 Sekunden nachdenkt, ist auch klar, wieso.

Vielleicht solltest du auch mal diese 30 Sekunden investieren, bevor du
postest. Das ist ja haarsträubend!

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]

Bernd Laengerich schrieb:

Am 10.05.2015 um 12:19 schrieb Hans-Peter Diettrich:

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

AFAIR waren das 5 ROMs a 4kB, von denen einer direkt auf der
AIM-65-Platine und 4 auf einer Erweiterungsplatine installiert wurden.

Auf meinen AIM paßten die 2 ROMs direkt drauf. Allerdings paßten FORTH
und Pascal nicht gemeinsam aufs Motherboard, deshalb kann ich mir eine
Zusatzplatine (mit Umschalter?) gut vorstellen.

Wieviel davon Editor, Compiler und wieviel Runtime waren weiß ich nicht.
Das sagt weiterhin nichts über den 8085-Code aus noch über die Größe des
EPROM-Bausteines den das Eval-Board vertrug (es waren 8kB IIRC).
6502-Code war i.d.R etwas kompakter als solcher für den 8080.
Das eigentliche Programm waren nur wenige zig Byte, der Rest war
"Pascal-Bloat".

Bei Pascal kommt es noch drauf an, ob nativer oder P-Code erzeugt wird.
Entsprechend wird der Compiler oder die VM größer. Ich habe damals fast
nur in FORTH programmiert, zu Pascal kam ich so richtig erst mit Delphi.

DoDi

 

[Franz Glaser]

Am 10.05.2015 15:12, schrieb Johannes Bauer:

On 10.05.2015 13:55, Hans-Peter Diettrich wrote:

Ich hätte ja nichts dagegen, wenn autoconf, automake oder wasauchimmer
zum*Sprachstandard* von C hinzugefĂźgt wĂźrde.

Oh. Mein. Gott.
*)

Mein persĂśnlicher Albtraum: Du im C-Standard-Komitee.

.... also mir() wärs wurscht :->

*) ... aka VORSEHUNG

GL
--
Der Zeitgeist ist das, was grad die Mehrheit unter der
Normalverteilungsglocke fßr richtig hält. Hinten sind die altmodischen
Irren und vorne sind die progressiven Irren, beide kämpfen gegen die
mittelmäßige Mehrheit.

 

[Hans-Peter Diettrich]

Myn Seudop schrieb:

Ach, weils soviel Spaß macht: Das 15 Jahre alte klassische (nicht
..NET) Visual Basic kommt dort noch vor Object Pascal (Delphi) und
reguläres Pascal wird selbst von Sprachen wie F# oder R überholt.

Mit VB habe ich noch vor Pascal programmiert, u.a. den VB3-Discompiler.
Danach wurde es mir aber zu klein und zu langsam, da bin ich auf Delphi
umgestiegen. Die VB-Sprachen waren eben nur OLE Wrapper, nichts für
"richtige" Programme.

DoDi

 

[Guido Grohmann]

MaWin schrieb:

"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

Hahahahahaha. Faß dich doch an deine eigene Nase!

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.

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?

Wollen sie das wirklich?

 

[MaWin]

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

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?
Wollen sie das wirklich?

Nur zu, wird wohl gestimmt haben, getroffene Hunde bellen.

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

 

[Ralph A. Schmid, dk5ras]

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.


-ras

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

 

[Bernd Laengerich]

Am 10.05.2015 um 15:20 schrieb Hans-Peter Diettrich:

Auf meinen AIM paßten die 2 ROMs direkt drauf. Allerdings paßten FORTH
und Pascal nicht gemeinsam aufs Motherboard, deshalb kann ich mir eine
Zusatzplatine (mit Umschalter?) gut vorstellen.

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.

Hier steht auch 5 ROMs:
http://www.classiccmp.org/cini/pdf/Rockwell/AIM-65%20Pascal.pdf 2-1ff

Bernd

 

[Klaus Butzmann]

Am 10.05.2015 um 12:19 schrieb Hans-Peter Diettrich:

Zum AIM-65 (6502) gab es ein Instant-Pascal im ROM. AFAIR waren das
gerade mal 8 KB, einschließlich Editor.
Nie gehört, kenne nur Basic, Forth, PL/65, man lernt immer noch dazu

Butzo

 

[Sieghard Schicktanz]

Hallo Johannes,

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.
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_. Warum
auch immer - einen Grund dafĂźr kann ich mir eigentlich nicht so recht
vorstellen. Daß das von den gängigen Debuggern auch ungern gesehen werden
kann, dagegen schon...

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

Hat wer behauptet, dass die dasselbe sein sollten?

....

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

Eben. Und so war das halt lange Zeit.

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

Stimmt, weil das ja auch Ăźberhaupt nicht der Fall ist. "Die GUI" sammelt da
garnichts, das ist schon eine Funktion des Compilers. Und es ist auch
durchaus nicht in der originalen "Spezifikation" von Pascal enthalten.
Die mpliziten Interface-Defintionen von Programmmoduln, den C-Header-
Dateien etwa entsprechend, sind ein Detail der Implementierungen, die
vom USCD-Pascal abstammen, und ist in gleicher Art, nur mit einigen
Erweiterungen, im ISO-Standard enthalten.

lediglich das GerĂźst, das jemand um eine Sprache gebaut hat und vĂśllig
unabhängig von der darunterliegenden Sprache.

Strengenommen ist alles, was Ăźber die Umsetzung des Quellentextes zu
weiterzuverarbeitenen Ausgangsdaten hinausgeht, nicht mehr Bestandteil
der _Sprache_. Auch standardisierte Laufzeitbibliotheken nicht, mit denen
C anderen Sprachen durchaus etwas voraus hat - das sind zwar Bestandteile
des Implementierungs-Standards, aber nicht der _Sprache_.

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