Mikrocontroller: "Compiler-Optimizer-Fehler" finden?

[Reinhardt Behm]

Sieghard Schicktanz wrote:

Hallo Reinhardt,

Du schriebst am Mon, 16 Mar 2015 13:01:52 +0800:

Eine Variable hat immer einen Typ und der bestimmt, wie ihr Bitmuster zu
interpretieren ist.

Ja, aber der Typ bestimmt nur, wie ihr Inhalt im Kontext ihre Verwendung
zu interpretieren ist. Sobald die Variable an die "Außenwelt" kommt (das
kann schon durch Speichern der Fall sein), ist nur noch das Bitmuster
sichtbar.

Im ganzen Thread ging es bisher um die Bedeutung von Variablen und
AusdrĂźcken im Kontext eines C-Programms.

Was irgendwo wie im Speicher steht, geht nur das Programm was an.
Wenn auf externe Medien gespeichert wird, muss man sich sowieso viel mehr
Gedanken machen, Endianess ist nur ein Thema.
Beim Zugriff auf z.B. I/O-Devices ist man dann ganz abhängig von der
speziellen Architektur. Da schweigt sich der C-Standard mit Recht aus.

Wie soll sie denn bitte gleichzeitig zwei Werte besitzen?

Sie hat jeden Wert, der ihrem Bitmuster zugeschrieben werden kann.

Zudem werden nie nicht Variable sondern AusdrĂźcke mit == verglichen. Wenn
^^^^^^^^^...
die AusdrĂźcke einen logischen Wert hat (also nur 0 oder 1, z.B. als
^^^^^^^^^^^^^ ^^^?
Ok, Du wirst demnächst als Lektor eingestellt.

Ergebnis eines Vergleichs mit 0 wie oben), dann werden diese Werte
verglichen. Wenn Du da stattdessen int-Variable nimmst, dann werden deren
arithmetische Werte verglichen. Wo ist da jetzt das Problem?

Z.B. daß Du - in C - auch zwei Ausdrücke vergleichen kannst, die
_unterschiedliche_ Typen besitzen, z.B. einer einen arithmetischen und
der andere einen booleschen.

Wenn Du bei mir programmieren wĂźrdest und boolsche mit arithmetischen Werten
vergleichst, wßrden wir ein ernsthaftes Gespräch fßhren.
Sauberes Programmieren bedeutet, nicht einfach Typen zu vermanschen. Selbst
wenn, wei im Fall des Vergleichs eines boolschen mit einem int Ausdruck, die
Sprache klar definertes Verhalten garantiert.

Mir scheint, die Typverwirrng ist eher in Deinem Kopf als in der Sprache
C. ^u

MĂśglich, C verursacht eben Verwirrung.

Aber nicht bei allen.

--
Reinhardt

 

[Reinhardt Behm]

Sieghard Schicktanz wrote:

Hallo Reinhardt,

(wieder mehrere Antworten zusammengefasst.)

Du schriebst am Mon, 16 Mar 2015 13:15:08 +0800:

Java _ist_ eine C-basierte Sprache.

Nur weil die Leute, die Java implementieren keine andere Sprache als C
kennen und es dafĂźr benutzen, ist es noch lange nicht "C basierend".

Es ist C-_basiert_, nicht "-basiernd". Naja, Sprache...

Die _Syntax_ von Java ist der von C abgeschaut. Aber Du darfst durchaus
eine andere Definition von "basiert" definieren.


Du schriebst am Mon, 16 Mar 2015 13:10:38 +0800:

Nachdem in C von _jedem_ Datenobjekt die Adrese bestimmbar sein muß,
ist das so zu erwarten.

Du kennst keine bitfields? Davon gibt es auch keine Adresse.

Warum nicht? Sicher geht das. NatĂźrlich nur fĂźr die gesamte "struct", aber

Eben. Die ganze struct ist aber was ganz anderes als ein einzelnes bitfield.
Dein KĂźchentisch hat auch keine Postadresse, obwohl Dein Haus eine hat.

Du schriebst am Mon, 16 Mar 2015 13:09:20 +0800:

Das war ja auch eine große Neuerung bei den 32-Bit-Prozessoren, die es
...
Neu? das war schon bei der PDP11 so.

Achja richtig - und die war nur 16-bittig. Die war allerdings keine
Mikroprozessormaschine, bei den Mikroprozessoren geb's das aber erst mit
den 32-Bittern.

--
Reinhardt

 

[Peter Heitzer]

Michael Schwingen <news-1326478115@discworld.dascon.de> wrote:

On 2015-03-14, Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> wrote:
Ein Optimierer, der sequenziell geschriebene Statements umsortiert, macht
mit Scherheit _nicht_, was der Programmierer erwartet, auch wenn trotzdem
(meistens) das richtige Ergenis herauskommen sollte.

Nein.

Der Optimizer darf statements beliebig umsortieren, solange das herauskommt,
was der Sprachstandard fĂźr den angegebenen Quelltext fordert.

Das kann dem Programmierer auch egal sein: es kommt das Ergebnis heraus, das
seinem Quelltext entspricht, mit korrektem Ergebnis.

Wenn es Dir auf die Reihenfolge ankommt, weil das eben keine
Speicheroperationen sind, sondern es Nebenwirkungen gibt (z.B. auf
Registern), dann mußt Du als Programmierer mit passenden Barrieren dafür
sorgen, daß an den kritischen Stellen nicht umsortiert wird.

Die brauchst Du allerdings auch bei einem Compiler, der Ăźberhaupt nichts
umsortiert, weil das heutzutage auch in Hardware passiert (Cache,
Speichercontroller etc. - auch dort kann ein Lesezugriff einen vorher
ausgefĂźhrten Schreibzugriff Ăźberholen!), das kannst Du also nicht dem
Compiler ankreiden.

Mit OpenWatcom habe ich mal ein Programm geschrieben, daß den Timer im
PC auslesen sollte.
Die Funktion

unsigned int gett0() {
return (inp(0x40) & 0xff)+(inp(0x40)<<8);
}

lieferte immer falsche Werte. Nach Disassemblieren stellte sich heraus,
daß der Compiler Code erzeugte, bei dem High und Low (AH, AL) vertauscht
waren. Da er annahm, daß der Rückgabewert der Funktion inp() für
gleiche Übergabeparameter gleich ist, durfte er das sogar.
Erst ein Aufspalten in zwei getrennte Zuweisungen brachte das gewĂźnschte
Ergebnis.
Ein ähnlicher Fallstrick:
Wenn Anweisungen in C durch ';' getrennt werden, darf der Compiler diese
in beliebiger Reihenfolge abarbeiten. Eine streng sequenzielle Abarbeitung
wird durch ',' als Trenner erzwungen.

--
Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de
HTML mails will be forwarded to /dev/null.

 

[Michael Baeuerle]

Michael Schwingen wrote:

Jein. Es fehlen schon immer ein paar Details, die man gerne hätte - z.B.
Strukturdefinitionen, deren Speicherabbild genau definiert ist, so daß man
die auf Peripherieregister mappen kann. Das fehlt aber schon immer.

Ack. Der GCC kennt "__attribute__(packed)", aber auf manchen Maschinen
sind Zugriffe unaligned nicht möglich (siehe "Bus error" auf SPARC). Da
gibt es vielleicht einfach keine "schöne" Lösung die überall gut
funktioniert.

Moderne Compiler decken durchaus mehr kaputten Code auf, aber kaputt war der
schon vorher.

Nein. C wurde irgendwann mal für Unix geschrieben. Und aus diesem Umfeld
kam später z.B. das allgegenwärtige BSD socket API mit 'struct
sockaddr_storage' und anderem Kram für den explizit Typecasting vorge-
sehen ist. Die Aliasing Regeln mit denen es nun verboten ist, das so zu
benutzen wie es vorgesehen ist, wurden sicher von anderen Leuten hinzu-
gefügt (mutmaßlich den Compilerbauern).
Da das Interface von POSIX übernommen wurde ist es immer noch aktuell.
Da bleibt einem dann nur "-fno-strict-aliasing" für das ganze File oder
die Union. Letztere darf eigentlich nicht verwendet werden:
|
| [...] if the value of a member of a union object is used when the most
| recent store to the object was to a different member, the behavior is
| implementation-defined.

Aber es gibt diese Ausnahme:

| One special guarantee is made in order to simplify the use of unions:
| If a union contains several structures that share a common initial
| sequence (see below), and if the union object currently contains one
| of these structures, it is permitted to inspect the common initial
| part of any of them anywhere that a declaration of the completed type
| of the union is visible. Two structures share a common initial
| sequence if corresponding members have compatible types (and, for
| bit-fields, the same widths) for a sequence of one or more initial
| members.

.... die es dann doch erlaubt.

Oder habe ich eine weitere Option übersehen?

 

[Reinhardt Behm]

On 18.03.2015 18:51, Michael Baeuerle wrote:

Michael Schwingen wrote:

Jein. Es fehlen schon immer ein paar Details, die man gerne hätte - z.B.
Strukturdefinitionen, deren Speicherabbild genau definiert ist, so daß man
die auf Peripherieregister mappen kann. Das fehlt aber schon immer.

Ack. Der GCC kennt "__attribute__(packed)", aber auf manchen Maschinen
sind Zugriffe unaligned nicht möglich (siehe "Bus error" auf SPARC). Da
gibt es vielleicht einfach keine "schöne" Lösung die überall gut
funktioniert.

Moderne Compiler decken durchaus mehr kaputten Code auf, aber kaputt war der
schon vorher.

Nein. C wurde irgendwann mal für Unix geschrieben. Und aus diesem Umfeld
kam später z.B. das allgegenwärtige BSD socket API mit 'struct
sockaddr_storage' und anderem Kram für den explizit Typecasting vorge-
sehen ist. Die Aliasing Regeln mit denen es nun verboten ist, das so zu
benutzen wie es vorgesehen ist, wurden sicher von anderen Leuten hinzu-
gefügt (mutmaßlich den Compilerbauern).
Da das Interface von POSIX übernommen wurde ist es immer noch aktuell.
Da bleibt einem dann nur "-fno-strict-aliasing" für das ganze File oder
die Union. Letztere darf eigentlich nicht verwendet werden:
|
| [...] if the value of a member of a union object is used when the most
| recent store to the object was to a different member, the behavior is
| implementation-defined.

Nicht _undefined_ aber _implementation-defined_. Das macht auch Sinn.
Eine Uminterpretierung einer float in eine int ist halt abhängig davon,
wie die Darstellung von float und int ist. Das Verhalten im Standard
festzuschreiben, würde bedeuten, dass die interne Darstellung von Typen
festgelegt wäre.

Aber es gibt diese Ausnahme:

| One special guarantee is made in order to simplify the use of unions:
| If a union contains several structures that share a common initial
| sequence (see below), and if the union object currently contains one
| of these structures, it is permitted to inspect the common initial
| part of any of them anywhere that a declaration of the completed type
| of the union is visible. Two structures share a common initial
| sequence if corresponding members have compatible types (and, for
| bit-fields, the same widths) for a sequence of one or more initial
| members.

.... die es dann doch erlaubt.

Das heißt aber auch, dass Du dabei nur auf Member gleichen (oder
kompatiblem) Type zugreifen darfst.
Also so was wie viele structs in einer union mit je einem unit8_t als
erstes, der als Typkennung für struct verwendet wird.

Oder habe ich eine weitere Option übersehen?

--
Reinhardt

 

[Michael Baeuerle]

Reinhardt Behm wrote:

Michael Baeuerle wrote:

[...]
Aber es gibt diese Ausnahme:

| One special guarantee is made in order to simplify the use of unions:
| If a union contains several structures that share a common initial
| sequence (see below), and if the union object currently contains one
| of these structures, it is permitted to inspect the common initial
| part of any of them anywhere that a declaration of the completed type
| of the union is visible. Two structures share a common initial
| sequence if corresponding members have compatible types (and, for
| bit-fields, the same widths) for a sequence of one or more initial
| members.

.... die es dann doch erlaubt.

Das heißt aber auch, dass Du dabei nur auf Member gleichen (oder
kompatiblem) Type zugreifen darfst.
Also so was wie viele structs in einer union mit je einem unit8_t als
erstes, der als Typkennung für struct verwendet wird.

Ja, für die diversen Varianten von 'struct sockaddr' reicht das aber
prinzipiell zumindest um dereferenzieren und in das Typfeld vom Typ
'sa_family_t' (bei GNU und BSD üblicherweise 'unsigned short int')
schauen zu dürfen. Vorausgesetzt dieses ist das erste Feld bzw. die
Elemente davor sind identisch.

Leider muss ein POSIX konformes OS einem das nicht garantieren und man
ist auf OS spezifische Doku angewiesen. Zitat aus:
<http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_socket.h.html>
|
| When a pointer to a sockaddr_storage structure is cast as a pointer to
| a sockaddr structure, the ss_family field of the sockaddr_storage
| structure shall map onto the sa_family field of the sockaddr
| structure. When a pointer to a sockaddr_storage structure is cast as a
| pointer to a protocol-specific address structure, the ss_family field
| shall map onto a field of that structure that is of type sa_family_t
| and that identifies the protocol's address family.

Es ist nicht gefordert, dass es das erste Feld ist und undefiniert was
davor zu stehen hat (z.B. einmal eine interne Variable und das andere
Mal Padding gleicher Größe würde obiger POSIX Spezifikation genügen, den
Anforderungen von C99 aber nicht). Die Forderung nach der gleichen
"initial sequence" ist so nicht gesichert. Das wird natürlich kein
OS so implementieren, dass es mit dem zum System gehörenden Compiler
nicht funktioniert, aber ganz penibel betrachtet ist demnach die Union-
Lösung hier nicht portabel.

> > Oder habe ich eine weitere Option übersehen?

Falls nein:
=> Aliasing Optimierungen des Compilers im Zweifel lieber abschalten

 

[Stefan Reuther]

Peter Heitzer wrote:

Michael Schwingen <news-1326478115@discworld.dascon.de> wrote:
Die brauchst Du allerdings auch bei einem Compiler, der Ăźberhaupt nichts
umsortiert, weil das heutzutage auch in Hardware passiert (Cache,
Speichercontroller etc. - auch dort kann ein Lesezugriff einen vorher
ausgefĂźhrten Schreibzugriff Ăźberholen!), das kannst Du also nicht dem
Compiler ankreiden.

Mit OpenWatcom habe ich mal ein Programm geschrieben, daß den Timer im
PC auslesen sollte.
Die Funktion

unsigned int gett0() {
return (inp(0x40) & 0xff)+(inp(0x40)<<8);
}

lieferte immer falsche Werte. Nach Disassemblieren stellte sich heraus,
daß der Compiler Code erzeugte, bei dem High und Low (AH, AL) vertauscht
waren. Da er annahm, daß der Rückgabewert der Funktion inp() für
gleiche Übergabeparameter gleich ist, durfte er das sogar.

Dazu muss der Compiler nichtmal irgendwas besonderes annehmen. Das sind
zwei Funktionsaufrufe (zufällig mit dem gleichen Parameter, aber das ist
vollkommen egal), und die Reihenfolge dieser Aufrufe ist undefiniert.
Damit findet auch die Nebenwirkung - der Portzugriff - in undefinierter
Reihenfolge statt.


Stefan

 

[Stefan Reuther]

Michael Baeuerle wrote:

Leider muss ein POSIX konformes OS einem das nicht garantieren und man
ist auf OS spezifische Doku angewiesen. Zitat aus:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_socket.h.html
|
| When a pointer to a sockaddr_storage structure is cast as a pointer to
| a sockaddr structure, the ss_family field of the sockaddr_storage
| structure shall map onto the sa_family field of the sockaddr
| structure. When a pointer to a sockaddr_storage structure is cast as a
| pointer to a protocol-specific address structure, the ss_family field
| shall map onto a field of that structure that is of type sa_family_t
| and that identifies the protocol's address family.

Es ist nicht gefordert, dass es das erste Feld ist und undefiniert was
davor zu stehen hat (z.B. einmal eine interne Variable und das andere
Mal Padding gleicher Größe würde obiger POSIX Spezifikation genügen, den
Anforderungen von C99 aber nicht). Die Forderung nach der gleichen
"initial sequence" ist so nicht gesichert.

Naja, da POSIX (bzw. SUS) immer schön erwähnt, "wenn diese Spezifikation
im Widerspruch zur C-Spec steht, hat C Vorrang", gehe ich mal davon aus,
dass mit "shall map onto..." die Äquivalenz konform mit dem C-Standard
gemeint ist, also die gemeinsame "initial sequence".

Compiler- und OS-Bauer sind ja nicht vorsätzlich böse.


Stefan

 

[Michael Baeuerle]

Stefan Reuther wrote:

Michael Baeuerle wrote:

Leider muss ein POSIX konformes OS einem das nicht garantieren und man
ist auf OS spezifische Doku angewiesen. Zitat aus:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_socket.h.html
|
| When a pointer to a sockaddr_storage structure is cast as a pointer to
| a sockaddr structure, the ss_family field of the sockaddr_storage
| structure shall map onto the sa_family field of the sockaddr
| structure. When a pointer to a sockaddr_storage structure is cast as a
| pointer to a protocol-specific address structure, the ss_family field
| shall map onto a field of that structure that is of type sa_family_t
| and that identifies the protocol's address family.

Es ist nicht gefordert, dass es das erste Feld ist und undefiniert was
davor zu stehen hat (z.B. einmal eine interne Variable und das andere
Mal Padding gleicher Größe würde obiger POSIX Spezifikation genügen, den
Anforderungen von C99 aber nicht). Die Forderung nach der gleichen
"initial sequence" ist so nicht gesichert.

Naja, da POSIX (bzw. SUS) immer schön erwähnt, "wenn diese Spezifikation
im Widerspruch zur C-Spec steht, hat C Vorrang", gehe ich mal davon aus,
dass mit "shall map onto..." die Äquivalenz konform mit dem C-Standard
gemeint ist, also die gemeinsame "initial sequence".

Der Spruch, dass C Vorrang hat, steht aber nur bei Funktionen dabei die
es früher in C gar nicht gab, und die dann geändert wurden um mit C99
kompatibel zu sein (wie z.B. 'snprintf()'). Bei den Funktionen des
Socket API steht nichts in der Art dabei.

Genormt ist aber ein C99 Compiler, d.h. irgendwie sollte das Socket API
damit natürlich legal nutzbar sein.

> Compiler- und OS-Bauer sind ja nicht vorsätzlich böse.

Ja, aber erstere vielleicht manchmal etwas akademisch praxisfern.

 

[Reinhard Forster]

Am Wed, 18 Mar 2015 13:36:55 +0800 schrieb Reinhardt Behm:

MĂśglich, C verursacht eben Verwirrung.

Aber nicht bei allen.

-> "Real Programmers don't use Pascal"

Das MUSSTE jetzt endlich raus ...

Ade

Reinhard

 

[Reinhardt Behm]

Reinhard Forster wrote:

Am Wed, 18 Mar 2015 13:36:55 +0800 schrieb Reinhardt Behm:

MĂśglich, C verursacht eben Verwirrung.

Aber nicht bei allen.

-> "Real Programmers don't use Pascal"

Das MUSSTE jetzt endlich raus ...

Ade

Reinhard

Der Original-Artikel mit dem Titel sagt IIRC, sie benutzen nur FORTRAN und
die Variablen werden alle in einem COMMON Block gehalten und per EQUIVALENCE
auch noch Ăźberlagert.

--
Reinhardt

 

[Rolf Bombach]

Hans-Peter Diettrich schrieb:
> Johannes Bauer schrieb:

[C-Kritik]

Danke, ich habe selten eine dermassen kompakte und zutreffende Zusammenstellung
zu C gesehen. Bestätigt so ziemlich alles, was mir meine (ex-) Kollegen in
der Industrie erzählt haben.

--
mfg Rolf Bombach

 

[Johannes Bauer]

On 01.05.2015 18:33, Rolf Bombach wrote:
> Hans-Peter Diettrich schrieb:

Hans-Peter schrieb das vor 1.5 Monaten. Du antwortest aber auch schon
immer auf ziemlich olle Kamellen, so alt, dass ich mir das Posting aus
Google Groups ziehen musste, weil es mein Newsserver nicht mehr vorrätig
hält :-/

Danke, ich habe selten eine dermassen kompakte und zutreffende
Zusammenstellung
zu C gesehen. Bestätigt so ziemlich alles, was mir meine (ex-) Kollegen in
der Industrie erzählt haben.

Im Originalposting von Hans-Peter, das du leider komplett gesnippt hast,
ist leider eben auch viel Unsinn drin. Da wird aus vĂślligem Unwissen
heraus argumentiert. Beispielsweise die Behauptung aufgestellt, dass es
eine "vĂśllige Abwesenheit von UnterstĂźtzung bei der
Programm-Entwicklung" gäbe.

Das hat zum einen gar nichts mit der *Sprache* zu tun, zum anderen kennt
Hans-Dieter offenbar Ăźberhaupt keine Codeanalyse-Tools, die bei moderner
Programmentwicklung selbsredent zum Einsatz kommen. Auch bezĂźglich
Interner-Overflows hat er offenbar 20 Jahre Entwicklung einer
Programmiersprache komplett verschlafen und argumentiert mit
eingestaubtem PDP-11-Wissen.

Vielleicht sollte man sich zweimal Ăźberlegen, ob man die fachliche
Meinung von jemandem ernst nehmen soll und kann, der den Unterschied
zwischen C, C++ und der Arduino IDE nicht so wirklich verstanden hat.

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>

 

[Oliver Betz]

Johannes Bauer schrieb:

[...]

Danke, ich habe selten eine dermassen kompakte und zutreffende
Zusammenstellung
zu C gesehen. Bestätigt so ziemlich alles, was mir meine (ex-) Kollegen in
der Industrie erzählt haben.

Im Originalposting von Hans-Peter, das du leider komplett gesnippt hast,
ist leider eben auch viel Unsinn drin. Da wird aus völligem Unwissen

wollte ich auch schon antworten. FUD.

heraus argumentiert. Beispielsweise die Behauptung aufgestellt, dass es
eine "völlige Abwesenheit von Unterstützung bei der
Programm-Entwicklung" gäbe.

Das hat zum einen gar nichts mit der *Sprache* zu tun, zum anderen kennt
Hans-Dieter offenbar überhaupt keine Codeanalyse-Tools, die bei moderner
Programmentwicklung selbsredent zum Einsatz kommen. Auch bezüglich

hier widerspreche ich. Nur ein kleiner Teil der Entwickler
(einstelliger Prozentbereich) verwendet sie meines Wissens. Coding
Standards noch seltener (viele kennen nichtmal den Unterschied
zwischen Styleguide und Coding Standard).

Nicht nur ich behaupte: Man kann mit C fast so sicher arbeiten wie mit
ADA. Aber man muss selbst etwas dazu tun.

Servus

Oliver
--
Oliver Betz, Muenchen http://oliverbetz.de/

 

[Hans-Peter Diettrich]

Johannes Bauer schrieb:

Im Originalposting von Hans-Peter, das du leider komplett gesnippt hast,
ist leider eben auch viel Unsinn drin. Da wird aus vĂślligem Unwissen
heraus argumentiert. Beispielsweise die Behauptung aufgestellt, dass es
eine "vĂśllige Abwesenheit von UnterstĂźtzung bei der
Programm-Entwicklung" gäbe.

Wenn Du das nicht verstehst, dann zeugt das wohl von dem Unwissen, das
Du mir unterstellst.

Das hat zum einen gar nichts mit der *Sprache* zu tun, zum anderen kennt
Hans-Dieter offenbar Ăźberhaupt keine Codeanalyse-Tools, die bei moderner
Programmentwicklung selbsredent zum Einsatz kommen.

Mit Tools kann man vieles untersuchen. Es soll aber auch Sprachen geben,
die ohne Tools mehr UnterstĂźtzung fĂźr die Programmentwicklung bieten als
andere mit Tools.

Vielleicht sollte man sich zweimal Ăźberlegen, ob man die fachliche
Meinung von jemandem ernst nehmen soll und kann, der den Unterschied
zwischen C, C++ und der Arduino IDE nicht so wirklich verstanden hat.

Dann wäre ich (immer noch) dankbar fßr eine Erklärung, was die Arduino
IDE im Detail macht, und in welcher Version.

DoDi

 

[Stefan Reuther]

Hans-Peter Diettrich wrote:

Johannes Bauer schrieb:
Im Originalposting von Hans-Peter, das du leider komplett gesnippt hast,
ist leider eben auch viel Unsinn drin. Da wird aus vĂślligem Unwissen
heraus argumentiert. Beispielsweise die Behauptung aufgestellt, dass es
eine "vĂśllige Abwesenheit von UnterstĂźtzung bei der
Programm-Entwicklung" gäbe.

Wenn Du das nicht verstehst, dann zeugt das wohl von dem Unwissen, das
Du mir unterstellst.

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.

Das sind die Probleme die dann auftreten, wenn man in C etwas tun
mĂśchte, was man in den anderen Sprachen gar nicht kann. 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 muss nur dann nachgucken, ob es eine Thread-
Bibliothek gibt, wenn ich vorhabe, auf deren Abwesenheit zu reagieren
und nicht mich von vornherein auf Plattformen einschränke, fßr die schon
jemand eine VM mit Threads gebaut hat.

Das hat zum einen gar nichts mit der *Sprache* zu tun, zum anderen kennt
Hans-Dieter offenbar Ăźberhaupt keine Codeanalyse-Tools, die bei moderner
Programmentwicklung selbsredent zum Einsatz kommen.

Mit Tools kann man vieles untersuchen. Es soll aber auch Sprachen geben,
die ohne Tools mehr UnterstĂźtzung fĂźr die Programmentwicklung bieten als
andere mit Tools.

Die hĂśren dann halt an der Stelle auf, wo's runter auf das nackte Metall
geht.

NatĂźrlich ist ein Java-Klassenbrowser eine feine Sache. Dass Klassen-
browser fĂźr C++ nicht so dolle sind, liegt daran, dass man in C++ ein
'template<size_t N> class X' schreiben und als 'X<sizeof<Y>>' instanzi-
ieren kann, was ein Tool, das kein Compiler ist, halt nicht so gut verdaut.


Stefan

 

[Hans-Peter Diettrich]

Stefan Reuther schrieb:

Hans-Peter Diettrich wrote:

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.

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.

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.

Ich muss nur dann nachgucken, ob es eine Thread-
Bibliothek gibt, wenn ich vorhabe, auf deren Abwesenheit zu reagieren
und nicht mich von vornherein auf Plattformen einschränke, fßr die schon
jemand eine VM mit Threads gebaut hat.

Ich weiß weder, was eine VM damit zu tun hat, noch warum sowas irgendwie
auf C beschränkt sein sollte.

Das hat zum einen gar nichts mit der *Sprache* zu tun, zum anderen kennt
Hans-Dieter offenbar Ăźberhaupt keine Codeanalyse-Tools, die bei moderner
Programmentwicklung selbsredent zum Einsatz kommen.
Mit Tools kann man vieles untersuchen. Es soll aber auch Sprachen geben,
die ohne Tools mehr UnterstĂźtzung fĂźr die Programmentwicklung bieten als
andere mit Tools.

Die hĂśren dann halt an der Stelle auf, wo's runter auf das nackte Metall
geht.

Du meinst Assembler? Solche EinschĂźbe sollten in einem high-level
Assembler (wie C) eigentlich garnicht nĂśtig sein.

NatĂźrlich ist ein Java-Klassenbrowser eine feine Sache. Dass Klassen-
browser fĂźr C++ nicht so dolle sind, liegt daran, dass man in C++ ein
'template<size_t N> class X' schreiben und als 'X<sizeof<Y>>' instanzi-
ieren kann, was ein Tool, das kein Compiler ist, halt nicht so gut verdaut.

Ich weiß nicht, wieso Du obige Details irgendwie mit C in Verbindung
bringst. Und natĂźrlich kannst Du diejenigen Eigenschaften garnicht
aufzählen, die andere Programmiersprachen gegenßber C bieten, wenn Du
sie garnicht kennst :-]

DoDi

 

[Johannes Bauer]

On 04.05.2015 20:12, Hans-Peter Diettrich wrote:

Stefan Reuther schrieb:
Hans-Peter Diettrich wrote:

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.

Ja, mag sein. Heißt auch so.

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.

Meine GĂźte, ist das jetzt dein Ernst? Du lastest es der Sprache C an,
dass ein autoconf-Projekt nicht unter Windows kompiliert?

Ne, klar, ist auch voll die Schuld von Basic, dass ein Visual Basic
Programm nicht unter Linux zum Laufen zu bringen ist! Realitätscheck?

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.

Dann bleib doch einfach bei Free Pascal und halte dich mit
unqualifizierten Bemerkungen Ăźber Programmiersprachen, die du nicht im
Ansatz verstehst, ein bischen zurßck. Deine selbstgefällige,
Ăźberhebliche und trotzdem ignorante Art ist ziemlich irritierend.

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.

Wundert mich nicht.

Hast Du vielleicht die Probleme mit der
Endianness nicht verstanden?

Dunning-Kruger-Effekt, aber sowas von! Stefan hat das *sehr* gut verstanden.

Die dazugehĂśrenden Funktionen (ntoh...)
kĂśnnen in jeder Sprache implementiert und verwendet werden.

Eben, durch shift+mask. Was man sich sparen kann (und effizienter
hinschreiben kann), wenn man vorher durch autoconf die Endianness des
Targets ermittelt hat, und per Präprozessor eben bestimmten Code
verwendet (oder nicht).

Genau das hat Stefan gesagt.
Genau das hast du nicht verstanden.
Genau deshalb hattest du Stefan Unkenntnis unterstellt.

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]

Johannes Bauer schrieb:

On 04.05.2015 20:12, Hans-Peter Diettrich wrote:
Stefan Reuther schrieb:
Hans-Peter Diettrich wrote:
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.

Ja, mag sein. Heißt auch so.

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.

Meine GĂźte, ist das jetzt dein Ernst? Du lastest es der Sprache C an,
dass ein autoconf-Projekt nicht unter Windows kompiliert?

Ne, klar, ist auch voll die Schuld von Basic, dass ein Visual Basic
Programm nicht unter Linux zum Laufen zu bringen ist! Realitätscheck?

Mir ging es hauptsächlich darum, was fßr tolle Tools es zur
Programmentwicklung mit C so gibt. Und wie Leute auf die Idee kommen,
daß C eine besonders portable Sprache sei...

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.

Dann bleib doch einfach bei Free Pascal und halte dich mit
unqualifizierten Bemerkungen Ăźber Programmiersprachen, die du nicht im
Ansatz verstehst, ein bischen zurßck. Deine selbstgefällige,
Ăźberhebliche und trotzdem ignorante Art ist ziemlich irritierend.

Das liegt hauptsächlich an dem Vorwurf, daß ich irgendwas nicht
verstanden hätte, ßber das ich schreibe. Fßr sachdienliche Argumente bin
ich jederzeit dankbar, aber auf substanzlose Kritik reagiere ich nun mal
allergisch.

Und da nichts besseres nachkommt, spare ich mir weitere Kommentare.

DoDi

 

[Michael Baeuerle]

Hans-Peter Diettrich wrote:

Mir ging es hauptsächlich darum, was für tolle Tools es zur
Programmentwicklung mit C so gibt. Und wie Leute auf die Idee kommen,
daß C eine besonders portable Sprache sei...

C ist wohl die auf den meisten Plattformen verfügbare Hochsprache. Man
könnte daher ganz pragmatisch unterstellen, dass sie auch besonders
einfach auf neue Architekturen portiert werden kann. Insbesondere für
Microcontroller ist relevant, dass für C wenig Bloat erforderlich ist.
Das ist sicher auch der Grund für den Erfolg von C auf Maschinen mit
beschränkten Hardware-Ressourcen.

Du hast ja hier die Diskussionen zur Harvard-Architektur verfolgt. Warum
benutzt man auch für diese Maschinen (das nicht dafür vorgesehene und
auch nicht wirklich geeignete) C?

C ist weder besonders gut noch besonders schön. Es ist eine pragmatische
Lösung, die verfügbar ist und funktioniert (mehr oder weniger gut, ab-
hängig hauptsächlich vom Programmierer).

Seit Jahrzehnten werden ständig neue Sprachen erfunden, keine hat bisher
C verdrängen können.

==============

Und zum Thema autoconf:
Installiere auf deinem Windows Cygwin, so dass es die ganzen POSIX APIs
anbietet die GNU Software eben so benutzt, dann compiliert das Zeug mit
teilweise wenig Portierungsaufwand auch dort. Das Problem ist da weniger
die Sprache, sondern das OS-API (das bei POSIX halt nunmal auch C ist,
schließlich haben K&R seinerzeit C für Unix erfunden).