TIA Vorzeichen bei Integer Werten

[Martin2XK]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

für ein aktuelles Projekt verwende ich verschiedene Umrechnungsfunktionen, u a CONV und T_CONV. Die IEC-Prüfung habe ich bei meinen Bausteinen ebenfalls aktiviert, jetzt .. interessiere ich mich mehr dafür wie meine Steuerung mit den Werten genau umgeht bzw sie umrechnet. Um negative Werte zu vermeiden verwende ich z B den Datentyp UINT. Würde ich diesen in Bits aufteilen dann hätte ich nach dem binären Zahlensystem 1*2^0 + 1*2^1 + 1*2^2 ... usw bis 1*2^15. Damit wären alle 16 Bits belegt. Das ergibt 65535. Das verstehe ich und ist mir klar.

Wie aber ist das bei dem normalen Integer? Dieser hat doch ebenfalls 16 Bitstellen, die Rechnung wäre analog zu der von oben. Wo, an welcher Stelle genau steht denn das Vorzeichen? Der Wertebereich geht ja von -32768 bis 32768.

Ich würde mich über Hilfe freuen

 

[DeltaMikeAir]

Der Wertebereich geht ja von -32768 bis 32768.

nein, von -32768 bis 32767.

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Zweierkomplement – Wikipedia

de.wikipedia.org

 

[JesperMP]

Siehe '2er Kompliment'

Der Wertebereich geht ja von -32768 bis 32768

Nein, ein normalen signed INT geht von -32768 bis 32767.

... zu späht !!

 

[Glon]

Man kann auch schön mit dem Windows Taschenrechner rumspielen

 

[hucki]

Zuviel Werbung?
-> Hier kostenlos registrieren

nein, von -32768 bis 32767.

Anhang anzeigen 69865

Wieder so ein bescheuertes Bild!

Das Bit15 ist nicht das Vorzeichen sondern hat die Wertigkeit von -(2^15):

Datentyp UINT. ... usw bis 1*2^15. Damit wären alle 16 Bits belegt. Das ergibt 65535.

Wie aber ist das bei dem normalen Integer?

Im Prinzip also genauso, nur das es bei INT dann -1*2^15 ist.
(Alle anderen Bits haben bei INT und UINT die gleiche Wertigkeit.)

 

[DeltaMikeAir]

Wieder so ein bescheuertes Bild!

Was ist daran bescheuert? Ich denke mal das ist für Jedermann verständlich.

Aus dem Siemens Programmierhandbuch:

 

[PN/DP]

Anhang anzeigen 69865

Diese Siemens-Darstellung ist bekanntermaßen nicht korrekt. Ein 16 Bit INT enthält kein Vorzeichen-Bit, weil redundant. Das Vorzeichen-Bit hat immer den selben Wert wie das höchste Bit 15 des Zweierkomplements und braucht deshalb nicht mit abgespeichert werden. Das Bit 15 ist aber nicht das Vorzeichen-Bit, sondern das Bit mit der Wertigkeit -32768. Das Vorzeichenbit wird erst bei Berechnungen mit INT (Add, Sub, Mul, Div, ...) im Akku rekonstruiert.

PS: auch dieses Bild ist falsch. Hält sich leider schon seit vielen Jahren in vielen Siemens Dokumentationen...

Anhang anzeigen 69867

Harald

 

[Martin2XK]

Zuviel Werbung?
-> Hier kostenlos registrieren

Vielen Dank, wow so viele Antworten ... in kurzer Zeit

 

[Thruser]

Was ist daran bescheuert? Ich denke mal das ist für Jedermann verständlich.

Nach dem Bild wäre

0000_0000_0000_0001 = 1
1000_0000_0000_0001 = -1

es wird aber nach dem 2'er komplement gearbeitet daher
1111_1111_1111_1111 = -1

das ist schon ein Unterschied

Gruß

 

[hucki]

Was ist daran bescheuert?

Genau das hier:

Bit 15 entspricht den Dezimalwert -32.768.
Punkt.

Klar kann man das Vorzeichen des Gesamtwertes daran ablesen, aber es ist eben nicht (nur) das Vorzeichen.

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Bevor hier jetzt ein Shitstorm losgeht, ihr habt Recht. ( und ich meine Ruhe )

 

[JesperMP]

Bevor hier jetzt ein Shitstorm losgeht, ihr habt Recht

Es ist das (vor) Zeichen eines großen Mannes, dass er zugibt, wenn jemand anderes Recht hat.

 

[Martin2XK]

Ich habs verstanden

Bei INT sind alle Werte von 1*2^0 bis 1*2^14 positiv, das letzte (1*2^15) entspricht dem Wert -32768. (Die Zahl 1 in der Rechnung ist nur beispielhaft zu sehen)

Kann man dann auch sagen, dass UINT und WORD das gleiche sind? Oder gibt es zwischen diesen beiden einen Unterschied?

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Kann man dann auch sagen, dass UINT und WORD das gleiche sind?

Nein,
WORD hat keine Formatangabe, ist also "nur" ein Bitmuster.
UINT ist ein vorzeichenloses Zahlenformat.

Daher kannst du z.B. mit einem WORD auch keine Berechnungen durchführen:

 

[Martin2XK]

Ich kann beide Datentypen in Bitmuster zerlegen und auf diese Weise den Zahlenwert bestimmen der diesem Muster entspricht. Bei gleichem Bitmuster erhalte ich auch den gleichen Zahlenwert. Um den Unterschied zu verstehen, müsste ich mich für den Prozessor interessieren, also was er mit diesen beiden Bitmustern genau macht bzw. wie er sie verarbeitet. Oder anders formuliert: Warum kann der Prozessor mit dem Bitmuster eines WORD Datentyps nicht rechnen, was fehlt ihm in diesem Fall?

In welchen Fällen ist es sinnvoll mit WORD zu arbeiten?

 

[DeltaMikeAir]

Warum kann der Prozessor mit dem Bitmuster eines WORD Datentyps nicht rechnen, was fehlt ihm in diesem Fall?

Weil es formal falsch ist. Es ist ein Bitmuster, keine Zahl. Klar, UINT und WORD können den gleichen Bitstatus haben aber das eine ist eben eine Zahl und das andere ein Bitmuster.

Falls du trotzdem rechnen möchtest, ist eine Umwandlung notwendig. Z.b.:

WORD_TO_INT(DeinWord);

In welchen Fällen ist es sinnvoll mit WORD zu arbeiten?

Z.b. wenn man ein Bitmuster braucht ( Bitmeldungen Panel.... ).

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Oder anders formuliert: Warum kann der Prozessor mit dem Bitmuster eines WORD Datentyps nicht rechnen, was fehlt ihm in diesem Fall?

Der Prozessor kann das und hat dabei keinerlei Hemmungen.
Aber irgendwer hat sich ausgedacht, dass der Programmierer das nicht darf. Denn der Programmierer soll sich immer bewusst sein, was er da programmiert.
Logische Verknüpfungen (NOT, AND, OR, XOR, ..., Schiebe- und RotationsBefehle) nur mit BOOL und BYTE, WORD, DWORD, ... .
Arithmetische Verknüpfungen (INV, +, -, *, /, **, MOD, ...) nur mit vorzeichenlosen FestPunktZahlen USINT, UINT, UDINT, ... oder vorzeichenbehafteten FestPunktZahlen SINT, INT, DINT, ... oder GleitPunktZahlen REAL, ... .
INV natürlich nur bei vorzeichenbehafteten Zahlen, MOD (manchmal) nur bei FestPunktZahlen.
Damit also der Compiler stets prüfen kann, ob der Programmierer auf Zack ist, muss der Programmierer dem Compiler manchmal bis immer exakt mitteilen, welche DatenTypsKonvertierungen nötig sind bzw. wären.
Da diese Bevormundung nicht bei allen beliebt ist, wurden natürlich auch schon Abschwächungen wie die impliziten DatenTypWandlungen erschaffen.
Wie Du selbst schon schreibst, beinhalten DatenTypsKonvertierung nicht immer, dass der Inhalt geändert/konvertiert werden muss, sondern es wird manchmal nur der Aufkleber ausgewechselt, auf dem der DatenTyp angegeben ist. Das wird auch als TypeCasting bezeichnet.
Leider gibt es Compiler, die nicht so genau zwischen Konvertierung und TypeCast unterscheiden und dadurch auch den gewissenhaftesten Programmierer zur Verzweiflung bringen können.

In welchen Fällen ist es sinnvoll mit WORD zu arbeiten?

Na, logisch! Jedenfalls, wenn 16 Bit ausreichen!

Wer braucht eigentlich die unsigned (= vorzeichenlosen) FestPunktDatentypen?
Niemand, der die Grenzen eines vorzeichenbehaften FestPunktDatentyps nicht überschreiten will.
Aber komischerweise ist es sehr oft das höchstwertige Bit, das man unbedingt noch zusätzlich für die Darstellung einer positiven Zahl benötigt.
Denn, dafür eine doppelt so lange Variable zu spendieren (z.B. DINT statt INT oder LINT statt DINT), nur um 1 Bit mehr SpielRaum zu erhalten, wäre doch eine furchtbare Verschwendung, oder?
"Normal" ist die Darstellung als "ZweierKomplement" (SINT, INT, DINT, ...), also vorzeichenbehaftet. Die Interpretation als vorzeichenlos (USINT, UINT, UDINT, ...) empfinde ich als "aufgepfropft", aber manchmal doch nützlich, denn schliesslich müssen wir sparen, koste es, was es wolle.

Bitte das Wort "Vorzeichenbit" bei der Darstellung im "ZweierKomplement" immer mit grösster Vorsicht geniessen. Es ist nicht total falsch, verleitet aber immer wieder zu Missverständnissen und Verwirrung.