Rechenfehler bei *

Probier mal an Stelle von
> tc = 1953*256;

das hier

  tc = 1953L * 256L;

aus.

Und überleg dann, was geschieht.

Tip: Wie groß kann ein int werden? Und welchen Datentyp haben 
numerische Konstanten?

> (256*1953+32)

Wird in int gerechnet, und läuft über.

> 1953*256

Dito.

Elf schrieb:
> Hier die ursprüngliche Zeile (tc ist uint32_t):
>
> tc = 65536-(256*TimerCountOVF+TCNT0)/24;

Dass tc ein uint32_t ist, ist ziemlich irrelevant. Der Typ auf der 
linken Seite beeinflusst nämlich nicht, was auf der rechten Seite 
passiert.

In einer Zuweisung hat der Datentyp links keinen Einfluss auf die 
Rechnung rechts.

Dann kann ja auch gleich der passende Wettbewerbsartikel verlinkt 
werden:
http://www.mikrocontroller.net/articles/Plattformunabh%C3%A4ngige_Programmierung_in_C#Integer-Berechnungen

Der Compiler kann nicht überlaufen, aber dein Rechenergebnis.

tc = 1953*256

Int * Int = Int, nur das Ergebnis 499968 ist für Int zu groß - läuft 
also folglich über.

Elf schrieb:
> nur deshalb funktioniert, weil 600... automatisch schon ne Long ist und
> deshalb die ganze Rechenoperation in Long ausgeführt wird?

Ja. Willst Du Dir jetzt jeden Sachverhalt einzeln abgesegnen lassen?

Elf schrieb:
> PS: War das jetzt so genervt gemeint, wie ich es verstanden habe oder
> bin ich nur zu sensibel für dieses Forum?

Es war wahrscheinlich so gernervt gemeint wie du es verstanden hast aber 
das ist hier im Forum normal. Manch einer ist hier recht sensibel und 
reagiert dann so.

Deine Frage finde ich OK, denn das wird nur in wenigen Lehrbüchern 
wirklich erklärt. Diesen Stolperstein in C hab ich auch mitgenommen bei 
meinen ersten µC-Programier-Experimenten und stand erstmal mit fragendem 
Gesichtsausdruck übern Quellcode.

Michael Köhler schrieb:
> Diesen Stolperstein in C hab ich auch mitgenommen bei
> meinen ersten µC-Programier-Experimenten und stand erstmal mit fragendem
> Gesichtsausdruck übern Quellcode.

Ach, und in jeder anderen Hochsprache (neben C) oder gar in Assembler 
gibt es keine Datentypen und keinen Zahlenüberlauf?

Wegstaben Verbuchsler schrieb:
> Ach, und in jeder anderen Hochsprache (neben C) oder gar in Assembler
> gibt es keine Datentypen und keinen Zahlenüberlauf?

In PL/I ist das Produkt aus FIXED(5,2) und FIXED(7,1) vom Typ 
FIXED(13,3). Ein Überlauf kann in der Multiplikation innerhalb der 
Grenzen der Implementierung also nicht auftreten. Siehe 
http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/IBM3L101/3.3.1.2?SHELF=ibmsh306&DT=19950506201638#TBLFIG16

Im aus Unix stammenden "bc" (Basic Calculator) gibt es tatsächlich keine 
Datentypen und die Grenze zum Überlauf liegt (fast) nur in den 
Ressourcen des verwendeten Rechners.

Wegstaben Verbuchsler schrieb:
> Ach, und in jeder anderen Hochsprache (neben C) oder gar in Assembler
> gibt es keine Datentypen und keinen Zahlenüberlauf?

Was hat das mit dem Problem zu tun? Der TE ist über den Stein 
gestolpert, dass der Datentyp links vom =-Zeichen nicht die Bereich 
rechts vom =-Zeichen bestimmt sondern lediglich durch die Größe der 
benutzten Konstanten bestimmt wird. Ich rede jetzt übrigens nur von 
Beispielen, die dem hier im Thread genannten entsprechen aber ich bin 
mir auch sicher, dass hier der ein und andere Volldepp rumrennt, der 
immer noch ein Lücke findet. Ein bischen mitdenken und überlegen, was 
der Gegenüber gemeint haben könnte ist hier im Forum leider allzuoft als 
Mangelware zu betrachten... :(

c-hater schrieb:

> Das fällt sogar noch hinter die Fähigkeiten der aus heutiger Sicht
> steinzeitlichen Assembler zurück, zu denen C ursprünglich mal als
> Erweiterung in Form eines simplen Satzes primitiver Macros geschrieben
> wurde. Die Syntax von C hat sich seitdem zwar gar fürchterlich
> aufgebläht,

Eigentlich ... nicht.

Syntaktisch hat sich in C seit den Zeiten eines K&R nicht wahnsinnig 
viel getan. Gerade das C-Gremium ist sehr konservativ, wenn es darum 
geht, Änderungen an der Sprache abzusegnen.

> Das ist einfach unterirdisch. C halt. Eine Sprache für halbwissende
> Ignoranten.

Nicht wirklich.
C ist halt keine Sprache für Leute, die eine Tante zum Lulu-gehen 
brauchen.
Gerade deshalb ist es wichtig, sie von der Pieke auf zu lernen.

Und wie sich die Datentypen in einer Berechnung bestimmen, sorry, aber 
das steht tatsächlich in so ziemlich jedem Lehrbuch, das sein Geld wert 
ist. Denn das ist ein wichtiger Punkt in der Expression Evaluation.

> Ich folgere daraus, daß C-Programmierung ein erhebliches Potential
> hat, das menschliche Gehirn komplett auszubrennen.

Deine Folgerung ist falsch. Die Folgerung sie du ziehen solltest ist, 
dass man C nicht durch Zusammenfragen von anlassbezogenem Achtelwissen 
in Foren lernen kann, sondern sich von ordentlicher Literatur durch das 
Thema führen lassen sollte. Selbst dann bleiben noch Detailfragen offen, 
aber nicht mehr auf dem Level von "Wie bestimmen sich eigentlich die in 
Ausdrücken benutzten Datentypen und wie beeinflussen diese die Art und 
Weise, wie der Compiler die Operation in Code umsetzt".

So wie du das weiter oben ja auch schon korrekterweise angedeutet hast.


> Das Verhalten von C, per Default zur Entwurfszeit nur mit 16Bit
> zu rechnen

mit int, aber ... geschenkt

> und bei Bereichsüberschreitung von numerischen Literalen noch
> nicht einmal zu warnen

Dein Compilerbauer kann Warnungen einbauen soviele er will. Der 
C-Standard schreibt lediglich vor, welche Fehler gemeldet werden müssen. 
Aber Warnungen kann jeder machen wie er will.

>, war schon vor 40 Jahren idiotisch und ist es
> heute erst recht.

Ganz im Gegenteil. Es soll keinen Unterschied zwischen

1

  int j = 40000;

2

  int k = 40000;

3

4

  long l = j * k;

und

1

  long l = 40000 * 40000;

geben. Denn beides sind dieselben Operationen. Ob da jetzt Variablen 
involviert sind (und die 40000 auf irgendwelchen anderen Wegen 
entstehen, die für den Compiler nicht einsichtig sind), darf keinen 
Unterschied im Ergebnis machen. Also muss der Compiler genau das tun, 
wenn er den Ausdruck durch das Constant Folding vereinfacht, was auch 
passieren würde, wenn der Ausdruck zur Laufzeit berechnet werden würde. 
Wenn er nett ist, dann wirft er eine Warnung (wozu er nicht verpflichtet 
ist). Aber als Ergebnis muss Bit für Bit dasselbe rauskommen (inklusive 
Overflow) - dazu ist er durch die 'As-If' Regel verpflichtet. Und in 
früheren Jahren war das gar nicht so einfach, weil der Compiler zb für 
Floating Point Berechnungen dann auch zb das Verhalten der FPU der 
Zielhardware nachbilden musste.

Du magst C nicht. Das ist dein gutes Recht. Aber hör bitte auf mit 
deinem Halbwissen über C über die Sprache zu schimpfen. C ist sicher 
keine einfache Sprache und es gibt viele Details, die man wissen muss 
und ja, einige Details sind nicht so prickelnd gelöst. Aber all das kann 
man lernen und wenn man erst mal ein paar grundlegende Basisprinzipien 
verstanden hat, die wesentliche Grundlagen der Sprache bilden, dann 
versteht man bei manchen Dingen um einiges besser, warum die Dinge genau 
so sind wie sie sind. Viele empfinden C gerade im µC-Bereich als einen 
brauchbaren Mittelweg zwischen der Befreiung von den ebenfalls vielen 
kleinen Details, die man in der Assembler-Programmierung kennen und 
können und beherzigen muss und dem Overhead, dem man sich durch die 
Verwendung einer Hochsprache mit möglichst guter Fehlererkennung (auch 
zur Laufzeit) aufzwirbelt. Und in diesem Marktsegment macht C gar keine 
so schlechte Figur.

c-hater schrieb:
> Blödsinn.

Tja, warum wohl ist heute nicht Ada und auch nicht Assembler die
dominierende Sprache in der Controllerprogrammierung?  Offenbar sind
die Eigenwilligkeiten der Sprache C bei weitem nicht das Argument, das
du uns hier gern weiß machen möchtest.  Mit denen kann man sich
arrangieren, wenn man das einmal gelernt hat, der Aufwand für das
Lernen ist einmalig.  Der exorbitante Aufwand, den man allein für die
logische Fehlerfreiheit eines größeren Assemblerprogramms treiben muss
(und zwar sowohl bei der Erstellung als auch bei der Pflege) schließt
in fast allen praktisch relevanten Bereichen, in denen man mit der
Software Geld verdienen muss, die Nutzung von Assembler als erste Wahl
einfach mal aus.  Das kann und will keiner bezahlen, vor allem nicht
$KUNDE. ;-)

Ada wäre sicher interessant, aber ernsthaft durchgesetzt hat es sich
außerhalb einiger Nischen halt doch nicht.