Mikrocontroller: "Compiler-Optimizer-Fehler" finden?

[Marc Santhoff]

Hans-Peter Diettrich <DrDiettrich1@aol.com> schrieb:

Was "die" Sprache betrifft, mit autoconf muß der Entwickler
mindestens noch 4 weitere Sprachen beherrschen, um so ein Projekt
hinschreiben zu können.

In Free Pascal geht das einfacher.

Wenn man Free Pascal verteidigt, gehört dazu aber die Einsicht, daß auch
da ein "Make"-Tool dabei ist. Das Ding heißt fpcmake und hat eine
recht grausliche Syntax. Kann man benutzen, mit ordentlich Zeitaufwand,
um dann ein gewöhnliches Makefile erzeugt zu bekommen. Also lieber
Make-Syntax lernen, bzw. weiterbenutzen.

Neuerdings wird da fpmake entwickelt, daß wenigstens konsequent auf
Pascal-Syntax baut.

Und selbst Delphi kommt für Betrieb ohne IDE mit einem mitgebrachten
make.exe daher ...

Andere Tools, wie z.B. ppudump, ppumove, etc., sind letztlich die
Äquivalente zu den binären Helfern der C-Compiler.

Marc

 

[Marc Santhoff]

Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> schrieb:

Ja, die Debugger sind die schlimmste Erfindung der Software-Branche
und eindeutig C zuzurechnen.

Dann viel Spaß bei der Fehlersuche ohne ...

Marc

 

[MaWin]

"Hans-Peter Diettrich" <DrDiettrich1@aol.com> schrieb im Newsbeitrag
news:cqvag6Fgd9gU1@mid.individual.net...

>> Äh, nein, das Windows-API ist Pascal;

Ja.

> Ich kann mir nicht vorstellen, daß Windows in Pascal geschrieben wurde -

Wurde es auch nicht, sondern in C und Assembler.
Aber der Finder auf dem Mac wurde in Pascal geschrieben.

AFAIK kam nur die calling-convention die Pascal (callee räumt auf), die zu
minimal kürzerem Code führt.

Richtig. Un einige wenige Funktionen (mit variabler Parameteranzahl)
hatten auch die C-calling convention.


--
MaWin, Manfred Winterhoff, mawin at gmx dot net
Homepage http://www.oocities.org/mwinterhoff/
dse-FAQ: http://dse-faq.elektronik-kompendium.de/

 

[Wolfgang Allinger]

On 07 May 15 at group /de/sci/electronics in article mig2rd$nfu$1@news.albasani.net
<me@private.net> (MaWin) wrote:

"Hans-Peter Diettrich" <DrDiettrich1@aol.com> schrieb im Newsbeitrag
news:cqvag6Fgd9gU1@mid.individual.net...

Äh, nein, das Windows-API ist Pascal;

Ja.

Ich kann mir nicht vorstellen, daß Windows in Pascal geschrieben
wurde -

Wurde es auch nicht, sondern in C und Assembler.

Nö, in Basic und Assembler. Jedenfalls am Anfang.

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



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 Schwingen]

On 2015-05-07, Johannes Bauer <dfnsonfsduifb@gmx.de> wrote:

Die haben erst das experimentelle Programmieren
ermöglicht, das heute so verbreitet ist: Der Programmierer schreibt
irgendwelche Statements, schaut im Debugger, ob sie das tun, was er
braucht, und übernimmt die dann kritiklos in seinen Code...

Äh, ne. Ich weiß nicht, wo du Software entwickelt hast, aber außer im
privaten Frickelbereich habe ich von so einer Art, Software zu
entwickeln, noch nicht gehört. Würde mich auch sehr wundern, wenn das
irgendjemand praktizieren würde, klingt nämlich ziemlich ineffizient.

Doch, das sieht man leider teilweise so.

Nein, das will man nicht wirklich - und das ist auch von der Sprache
unabhängig.

cu
Michael

 

[Stefan Reuther]

Sieghard Schicktanz wrote:

Ja, die Debugger sind die schlimmste Erfindung der Software-Branche und
eindeutig C zuzurechnen.

Als Embedded-Heini nutze ich den Debugger vor allem fĂźr Assembler (zur
Validierung meines Codes und zur Überbrückung von Lücken im Manual).

In C kann ich ja schließlich printf benutzen, nachdem ich in Assembler
den seriellen Treiber zum Laufen bekommen habe.


Stefan

 

[Stefan Reuther]

Hans-Peter Diettrich wrote:

Stefan Reuther schrieb:
Du schilder(te)st zum Beispiel Probleme, die auftreten, wenn man ein
Programm von einem System auf ein anderes hebt, mittels "autoconfig",
das vermutlich eigentlich autoconf heißt.

Mag sein, daß das so heißt. Damit ist es meist unmöglich, ein so
vorbereitetes Linux-Projekt unter Windows zu kompilieren, allgemein
unter irgend einem System, das vom Erzeuger des Projekts nicht explizit
berĂźcksichtigt ist.

Cygwin (oder msys) installieren, glĂźcklich sein.

Hatte ich, nĂźtzt nichts.

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.

Das sind die Probleme die dann auftreten, wenn man in C etwas tun
mĂśchte, was man in den anderen Sprachen gar nicht kann.

Was "die" Sprache betrifft, mit autoconf muß der Entwickler mindestens
noch 4 weitere Sprachen beherrschen, um so ein Projekt hinschreiben zu
kĂśnnen.

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.

FĂźr *sein* Projekt, und fĂźr die Plattformen, die *dieser* Entwickler
kennt. Was dabei meist herauskommt, habe ich ja schon angegeben. Daß
Windows nicht zu den unterstßtzten Plattformen zählt, ergibt sich dann
fast zwangsläufig aus der Abneigung oder Unkenntnis von GNU
Programmierern gegenĂźber nicht-POSIX Plattformen.

Nochmal langsam zum Mithäkeln fßr Trolle: wenn in Free Pascal irgendwas
"einfacher" zu portieren ist als in C, liegt das daran, dass jemand die
Portierungsarbeit inkl. autoconf und Co. bereits getan hat.

Er hätte kein portables Netzwerkmodul fßr *ix und Windows geschrieben,
wenn er nicht-POSIX-Plattformen gegenßber abgeneigt wäre.

Das geht solange gut, wie das Free-Pascal-Team schneller
ist mit dem Portieren ihres Compilers auf neue Plattformen als du mit
dem Verwendenwollen. Ich hab durchaus schon Ăśfters C-Software auf
Plattformen zum Laufen gebracht, die der Originalautor gar nicht kannte.

Das liegt an der notwendigen Einarbeitung in die Eigenschaften dieser
anderen Plattformen (CPU, OS und Bibliotheken), sowie deren Einbindung
in den Compiler und dessen Bibliotheken. Wer das nicht will oder kann,
muß immer darauf warten, daß es andere für ihn tun.

Und da du dich nicht in C oder Make einarbeiten willst, wirst du halt
immer darauf warten, das das jemand fĂźr dich tut.

Ich muss nur
dann nachgucken, wie der Endian des Prozessors ist, wenn ich vorhabe,
größere Datenmengen in Byteblobs zu wandeln und zu verarbeiten (und
nicht per Hand mittels Shift+Mask von einem 'long'-Array in ein 'byte'-
Array kopieren).

Ich weiß nicht, was Du meinst. Hast Du vielleicht die Probleme mit der
Endianness nicht verstanden? Die dazugehĂśrenden Funktionen (ntoh...)
kĂśnnen in jeder Sprache implementiert und verwendet werden.

Ein hĂźbsch ineffizientes 'ntoh' ist kein Problem.

Und mit "inline" auch hĂźbsch effizient. Das ist eine der Erweiterungen
von C++, die eine Schwäche von C (untypisierte Makros) abmildert.

Hast du vielleicht das Problem nicht verstanden? (<- dein Satz)

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.

Wenn man Kryptozeug implementiert oder Bildverarbeitung, will man genau
ein Wort aus dem Speicher holen, mit einer Instruktion, und dann damit
rechnen.

Auch in C kann ich Code schreiben, dessen GĂźltigkeit von einem Tool, das
kein Compiler ist, nicht beurteilt werden kann.
int foo[sizeof(struct X) == 42];

Das ist einer der GrĂźnde, warum ich Makros und Tools nicht mag.

An obiger Zeile ist weder ein Makro, noch ein Tool beteiligt.

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.

Bei C# war das genau umgekehrt, dort hat Microsoft Leute eingekauft,
welche genug von Sprachen verstanden, um ein neues und allgemein
verwendbares Grundkonzept (.NET) zu erstellen, ohne RĂźcksicht auf
Rßckwärts-Kompatibilität.

C# ist eine me-too-Sprache zu Java, die die Schmutzecken von Delphi in
die C-Welt rettet (der Unterschied zwischen 'reference types' namens
'class' und 'value types' namens 'struct' entspricht dem Unterschied
'class' vs. 'object' in Delphi und taugt eigentlich zu nix außer zum
Verwirrungstiften), und die außerdem an galoppierender Featuritis
leidet, mit der sie leider nun auch Java angesteckt haben. Von
Innovation und großem Sprachverständnis zeugt daran gar nichts.

Was Microsoft besser kann als andere ist ein sprachĂźbergreifendes
Objektmodell zu schaffen und praktisch einzusetzen (COM).


Stefan

 

[Sieghard Schicktanz]

Hallo Stefan,

Du schriebst am Thu, 07 May 2015 18:55:30 +0200:

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.

Genau aus diesem Grund - "Include-Guard" - ist es eben _nicht_ so, daß "der
Compiler [Include-Files] in einem Compilerlauf ein Headerfile nur einmal
liest". Wie sonst, außer durch jedesmaliges neues Einlesen _und Auswerten_,
könnte er feststellen, ob außer dem "Include-Guard" evtl. noch was in dem
File steht? Ein Include-File _muß_ jedemal vollständig geparst werden,
wobei natĂźrlich Vereinfachungen mĂśglich sind, wenn gewisse Direktiven
erkannt wurden, die einen bestimmten Abschluß brauchen und den Text
dazwischen als irrelevant gelten lassen. Aber die Abschluß-Direktive muß
halt trotzdem gesucht 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 Johannes,

Du schriebst am Thu, 07 May 2015 16:49:23 +0200:

Ja, die Debugger sind die schlimmste Erfindung der Software-Branche und
eindeutig C zuzurechnen.

Nee, Debugger sind ein echter Segen. Man muss sie nur einzusetzen wissen.

Es gibt durchaus sinnvolle Anwendungen, das ist schon richtig. Aber sie
verleiten halt viele weniger versierte "Softwerker" zum xperimentellen
Programmieren.

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.

Die haben erst das experimentelle Programmieren
....
Äh, ne. Ich weiß nicht, wo du Software entwickelt hast, aber außer im
privaten Frickelbereich habe ich von so einer Art, Software zu

Nicht entwickelt - sowas muß man leider immer wieder benutzen.
Spezialsachen fĂźr firmeninterne Verarbeitung, erstellt von Leuten, die
halt gerne mit Computern spielen wollen und sich deswegen bereit erklären,
fĂźr "die Anwendung mal schnell ein Programm zu schreiben".

entwickeln, noch nicht gehĂśrt. WĂźrde mich auch sehr wundern, wenn das
irgendjemand praktizieren wßrde, klingt nämlich ziemlich ineffizient.

Ja, klar, ist es auch, und fehlerträchtig dazu. Sowas funktioniert nur in
dem Bereich, fĂźr den es gemacht wurde, und nur mit den dort "Ăźblichen"
Daten.
(Allerdings war das durchaus ein wenig "spitz" gemeint.)

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

 

[Hartmut Kraus]

Am 07.05.2015 um 18:22 schrieb Wolfgang Allinger:

On 07 May 15 at group /de/sci/electronics in article mig2rd$nfu$1@news.albasani.net
me@private.net> (MaWin) wrote:

"Hans-Peter Diettrich" <DrDiettrich1@aol.com> schrieb im Newsbeitrag
news:cqvag6Fgd9gU1@mid.individual.net...

Äh, nein, das Windows-API ist Pascal;

Ja.

Ich kann mir nicht vorstellen, daß Windows in Pascal geschrieben
wurde -

Wurde es auch nicht, sondern in C und Assembler.

NĂś, in Basic und Assembler. Jedenfalls am Anfang.

Basic mit Sicherheit nicht. Die API durchweg in C und Assembler, Win2k
nun Ăźberwiegend in C++ ...

--
http://www.hkraus.eu/

 

[Gerhard Hoffmann]

Am 07.05.2015 um 15:54 schrieb Reinhardt Behm:

On 08.05.2015 00:40, Stefan Reuther wrote:
Sieghard Schicktanz wrote:
Ja, die Debugger sind die schlimmste Erfindung der Software-Branche und
eindeutig C zuzurechnen.

weapons grade nonsense.

Als Embedded-Heini nutze ich den Debugger vor allem fĂźr Assembler (zur
Validierung meines Codes und zur Überbrückung von Lücken im Manual).

In C kann ich ja schließlich printf benutzen, nachdem ich in Assembler
den seriellen Treiber zum Laufen bekommen habe.


Stefan

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

Eigentlich haben die neuesten CPUs seit etwa 15 Jahren sogenannte
Breakpoint-Register, da wird das doch glatt von Hardware erschlagen,
und, man stelle sich vor, Debugger kĂśnnen mit so was transparent
und in Echtzeit umgehen.

Man kann sich natĂźrlich auch mit printf()s Heisenbugs bauen.
(Observing it affects the outcome.)

Gruß, Gerhard

 

[Hans-Peter Diettrich]

Holger Petersen schrieb:

Hans-Peter Diettrich <DrDiettrich1@aol.com> writes:

Ich kann mir nicht vorstellen, dass Windows in Pascal geschrieben wurde -
dann haette MS ja erst mal ein Entwicklungssystem mit einem Pascal
Compiler liefern muessen.


recht OT
Eventuell hatte Microsoft ja sowas?

Hatte vielleicht, der Windows SDK wurde aber mit einem (ziemlich miesen)
C Compiler ausgeliefert.

Tatsache ist, das der EXCEl-Vorlaeufer fuer CP/M "Multipln" in Pascal ge-
schrieben wurde.

Microsoft hat viel Software eingekauft, auch Visual Basic stammt von
einer anderen Firma. Wer mag, kann ja mal abzählen, wieviele dieser
Programme in C geschrieben waren.

Und das es einen eigenen PASCAL-Compiler von Microsoft
gab - jedenfalls das Handbuch dazu stand bei mir rum

Vielleicht wurde der ja auch eingekauft, um die übrige eingekaufte
Software weiterzuentwickeln?

Und wenn wir schon OT sind, MS-DOS wurde auch erst später auf C
umgeschrieben, AFAIR in Version 3. Ich beweifle aber mal, daß die
Vorgänger in Pascal geschrieben waren ;-)

DoDi

 

[Hans-Peter Diettrich]

MaWin schrieb:

"Hans-Peter Diettrich" <DrDiettrich1@aol.com> schrieb im Newsbeitrag
news:cqvag6Fgd9gU1@mid.individual.net...

Äh, nein, das Windows-API ist Pascal;

Ja.

Ich kann mir nicht vorstellen, daß Windows in Pascal geschrieben wurde -

Wurde es auch nicht, sondern in C und Assembler.
Aber der Finder auf dem Mac wurde in Pascal geschrieben.

Auf dem Mac war Pascal sowieso Standard. Was zumindest beweist, daß man
auch Betriebssysteme in Pascal schreiben kann. Erst viel später wurde
auf Objective-C umgestellt.

DoDi

 

[Hans-Peter Diettrich]

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. Den Rest erledigt der Compiler
und Linker. Nur veralteten Compilern, wie für C, muß man jede einzelne
Quelldatei händisch vorgeben.

Das sind die Probleme die dann auftreten, wenn man in C etwas tun
mĂśchte, was man in den anderen Sprachen gar nicht kann.
Was "die" Sprache betrifft, mit autoconf muß der Entwickler mindestens
noch 4 weitere Sprachen beherrschen, um so ein Projekt hinschreiben zu
kĂśnnen.

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?

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. Für automake mußten die Projekte
noch weiter verunstaltet werden.

Von einem nĂźtzlichen Portierungs-/CrossCompile-System wĂźrde ich deshalb
erwarten, daß so eine Anpassung nur einmal durchgeführt werden muß,
nicht für jedes einzelne Projekt, und daß der Benutzer nur noch die
Zielplattform angeben muß, zusätzlich zum Startmodul. So läuft das
jedenfalls bei Free Pascal.

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

Wenn man Kryptozeug implementiert oder Bildverarbeitung, will man genau
ein Wort aus dem Speicher holen, mit einer Instruktion, und dann damit
rechnen.

Auch in C kann ich Code schreiben, dessen GĂźltigkeit von einem Tool, das
kein Compiler ist, nicht beurteilt werden kann.
int foo[sizeof(struct X) == 42];
Das ist einer der GrĂźnde, warum ich Makros und Tools nicht mag.

An obiger Zeile ist weder ein Makro, noch ein Tool beteiligt.

Stimmt, in C ist ja sizeof ein Operator. Ich erinnere mich in diesem
Zusammenhang an eine Systembibliothek, in der sich der Programmierer
ßber die Unfähigkeit des Compiler(bauer)s ausgelassen hat, weil es nicht
so funktionierte, wie er sich das vorgestellt hat: "shit for brains".

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.

BTW auch ein Guard kann nicht verhindern, daß alle Header für jedes
Modul nochmal verarbeitet werden mĂźssen. Hacks wie "precompiled headers"
sind unsicher und in anderen Sprachen nicht einmal notwendig.


Aber wieso streiten wir jetzt schon wieder Ăźber die Vor- und Nachteile
von Programmiersprachen und Entwicklungssystemen, an denen wir (als
Benutzer) sowieso nichts ändern kÜnnen? Das ändert nichts, insbesondere
nicht daran, daß *ich* in C etliche nützliche Features von Pascal vermisse.

DoDi

 

[Hans-Peter Diettrich]

Marc Santhoff schrieb:

Hans-Peter Diettrich <DrDiettrich1@aol.com> schrieb:

Was "die" Sprache betrifft, mit autoconf muß der Entwickler
mindestens noch 4 weitere Sprachen beherrschen, um so ein Projekt
hinschreiben zu können.

In Free Pascal geht das einfacher.

Wenn man Free Pascal verteidigt, gehört dazu aber die Einsicht, daß auch
da ein "Make"-Tool dabei ist.
[...]

Ich verteidige Free Pascal nicht, ich benutze es nur (indirekt über
Lazarus). Mit der Implementierung bin auch ich nicht immer glücklich, in
Anbetracht der Möglichkeiten, die dort IMO nicht richtig genutzt werden.

Daß Free Pascal Teile der GNU Toolchain benutzt, ist doch völlig
einsichtig - das spart die Entwicklung eines eigenen Linkers, Debuggers
etc. für jede einzelne Plattform, und erlaubt die Verwendung von fremden
Bibliotheken auf ABI Ebene.

Noch viel lieber wäre mir ein Pascal Frontend zu gcc (oder LLVM...), mit
dem sich noch viel mehr Arbeit am Compiler und drumrum einsparen ließe,
die dann in andere nützliche Features gesteckt werden könnte. Sowas
würde ich mir auch selbst zutrauen, davon hält mich nur der Aufwand für
die Einarbeitung in die Interna von gcc ab. 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.

DoDi

 

[Reinhardt Behm]

Gerhard Hoffmann wrote:

Am 07.05.2015 um 15:54 schrieb Reinhardt Behm:
On 08.05.2015 00:40, Stefan Reuther wrote:
Sieghard Schicktanz wrote:
Ja, die Debugger sind die schlimmste Erfindung der Software-Branche und
eindeutig C zuzurechnen.

weapons grade nonsense.

Als Embedded-Heini nutze ich den Debugger vor allem fĂźr Assembler (zur
Validierung meines Codes und zur Überbrückung von Lücken im Manual).

In C kann ich ja schließlich printf benutzen, nachdem ich in Assembler
den seriellen Treiber zum Laufen bekommen habe.


Stefan

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

Eigentlich haben die neuesten CPUs seit etwa 15 Jahren sogenannte
Breakpoint-Register, da wird das doch glatt von Hardware erschlagen,
und, man stelle sich vor, Debugger kĂśnnen mit so was transparent
und in Echtzeit umgehen.

Man kann sich natĂźrlich auch mit printf()s Heisenbugs bauen.
(Observing it affects the outcome.)

Gruß, Gerhard

Schon richtig. Wenn es wirklich so zeitkritisch wird, dann helfen
wahrscheinlich eh nur noch echte ICEs.
Aber wie Stefan schon schrieb, man arbeitet sich im embedded Bereich normal
von unten nach oben vorwärts. Die ganz zeitkritischen Teile sind im Bereich
des direkten Hardware-Zugriffs. Da ist dann ein freier Portpin wertvoller
als alles andere. Oszi dran und Timing messen oder auch als kleine Version
der printf(), um zu sehen, ob das Programm an der Stelle vorbeikommt. Sowas
beeinflusst auch noch das Timing, aber es hält sich doch in Grenzen. Wenn s
fĂźr sowas auch schon zu eng wird, sollte man doch mal Ăźber eine schnellere
CPU nachdenken.

Aber viel wichtiger als solche Hilfmittel sind klare Prozesse und Disziplin
bei der Software-Entwicklung. Dann muss man auch nicht die Fehler mĂźhsam
suchen, die sich ohne sowas einschleichen.
Die Hilfmittel sind dann nicht zum Suchen von Fehlern da, sondern zur
Verifikation des Programms gegen die Requirements.

--
Reinhardt

 

[Johannes Bauer]

On 08.05.2015 02:27, Hans-Peter Diettrich wrote:

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. Den Rest erledigt der Compiler
und Linker. Nur veralteten Compilern, wie für C, muß man jede einzelne
Quelldatei händisch vorgeben.

Aaaaah, jetzt dämmerts mir langsam: Du kannst also Compiler und Sprache
nicht auseinanderhalten. Du denkst offenbar, dass es ein Problem der
*Sprache* C ist, dass das Werkzeug, dass die Binaries erzeugt (Compiler)
nicht automatisch nach den Source-Files sucht.

Vielleicht solltest du erstmal grundlegende Begrifflichkeiten genau
studieren, bevor du diversen IT-Systemen, die du nur rudimentär
verstanden hast, diverse Schwächen attestierst.

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>

 

[Gerhard Hoffmann]

Am 08.05.2015 um 10:14 schrieb Johannes Bauer:

On 08.05.2015 02:27, Hans-Peter Diettrich wrote:

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. Den Rest erledigt der Compiler
und Linker. Nur veralteten Compilern, wie für C, muß man jede einzelne
Quelldatei händisch vorgeben.

Aaaaah, jetzt dämmerts mir langsam: Du kannst also Compiler und Sprache
nicht auseinanderhalten. Du denkst offenbar, dass es ein Problem der
*Sprache* C ist, dass das Werkzeug, dass die Binaries erzeugt (Compiler)
nicht automatisch nach den Source-Files sucht.

Man muss alte Compiler nicht wegwerfen. Man kann sie doch reparieren.
Ich glaube, das ist schon wieder eine Produktion von Holgers alter ego.

Gruß, G.

 

[MaWin]

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

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.
--
MaWin, Manfred Winterhoff, mawin at gmx dot net
Homepage http://www.oocities.org/mwinterhoff/
dse-FAQ: http://dse-faq.elektronik-kompendium.de/

 

[Michael Baeuerle]

Sieghard Schicktanz wrote:

Du schriebst am Thu, 07 May 2015 18:55:30 +0200:

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.

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.

Ich habe den cpp des GCC auch schon für einen non-C Compiler verwendet
(um Sachen zusammenzufügen und Konstanten einzusetzen *bevor* der
Compiler sie zu sehen bekommt). Die Schnittstelle zwischen den beiden
Komponenten beschränkte sich auf die Tags mit denen der Präprozessor
den aktuellen Dateiname und die Zeilennummer im Sourcecode mitteilt.
Der Compiler hätte aber auch ohne diese Information funktioniert,
lediglich die Fehlermeldungen wären nicht so aussagekräftig gewesen
bzw. hätten sich nur auf den Output des Präprozessors und nicht den
eigentlichen Quellcode beziehen können.

Wie sonst, außer durch jedesmaliges neues Einlesen _und Auswerten_,
könnte er feststellen, ob außer dem "Include-Guard" evtl. noch was in dem
File steht? Ein Include-File _muß_ jedemal vollständig geparst werden,
wobei natürlich Vereinfachungen möglich sind, wenn gewisse Direktiven
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
erkannt wurden, die einen bestimmten Abschluß brauchen und den Text
dazwischen als irrelevant gelten lassen. Aber die Abschluß-Direktive muß
halt trotzdem gesucht werden.

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.