SINT anstatt INT benutzen?

[ssyn]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe eine dumme Frage, hier gibt es nicht so viel los in Forum.

Ich sehe ganz oft, dass Datentyp INT in Programmen benutzt wird, sogar wenn da man benutzt die Zahlen von 0 bis 10, nicht mehr, z.B. bei CASE oder so.
INT ist 16 Bit, SINT ist 8 Bit.

Kann man anstatt INT doch SINT benutzen und ein bisschen Speicher in Programme sparen ? Oder da bringt grundsätzlich nix besonderes und/oder die Benutzung von INT hat irgendwelche eigene Vorteile?

 

[MCPC10]

Moin,
Klar kann man Speicher sparen, aber um mal ehrlich zu sein bei einer S7-1X00 ist Speicher das kleinste Problem. Ich würde bei Int bleiben dann ist der Bereich eigentlich fast immer groß genug (mal so im Betrieb ändern ist bei S7-1X00 nicht so der kracher => reinitalisieren), mann muss nicht dauernt konvertieren wenn man mit zBsp anderen variablen vergleicht (die dann int sind) und zu guter letzt AWL kann SINT nicht wirklich gut (ja mimi AWL ist doof aber die diskussion ist für später xD)

Gruß MCPC10

 

[codemonkey]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mir ist bisher noch nicht der Speicher ausgegangen, allerdings ich hin und wieder über das Problem gestolpert, dass das gewählte Zahlenformat dann doch nicht alles abdecken konnte.

Verwende ich SINT bzw USINT? Ja, in Strukturen welche dann in großen Arrays verwendet werden, wenn es z.B. auf RFID Datenträger geschrieben wird, bei Schnittstellen wo ich Big/Little-Endian Swap vermeiden kann.

 

[escride1]

Ich sehe ganz oft, dass Datentyp INT in Programmen benutzt wird, sogar wenn da man benutzt die Zahlen von 0 bis 10, nicht mehr, z.B. bei CASE oder so.
INT ist 16 Bit, SINT ist 8 Bit.

1) SINT ist bei einer 300/400 nicht nutzbar, daher wird "stylisch" vieles so gemacht wie man es früher gemacht hat. Neue Konzepte, neue Techniken, sind vielen älteren erfahrenen Programmierern ein Dorn im Auge.I
2) In einem äußerst kleinen Anteil aller Konvertierungen ist es aber auch nicht anders möglich.
3) Es wird für Reserven offen gehalten falls man doch mal größere Zahlen braucht.

 

[Blockmove]

@escride1
Jetzt grätsche ich mal ein:
Die alten Programmierer können mit Datentypen meist besser umgehen als die jungen Programmierer.
Bei den S5-Steuerungen musste man wirklich noch mit den Speicher geizen.
Datentypen mit einem Byte waren an der Tagesordnung.

 

[escride1]

Zuviel Werbung?
-> Hier kostenlos registrieren

@escride1
Jetzt grätsche ich mal ein:
Die alten Programmierer können mit Datentypen meist besser umgehen als die jungen Programmierer.
Bei den S5-Steuerungen musste man wirklich noch mit den Speicher geizen.
Datentypen mit einem Byte waren an der Tagesordnung.

Meinst Du damit wirklich mich? Was hat das nun, mit Ausnahme des gestrichenen Wortes "älteren", mit meinem Beitrag zu tun in dem ich kein Wort über Speicherverbrauch oder Optimierung verliere?
Ich dachte es wäre eindeutig das ich erfahrene Programmierer meine, die eben in der Regel älter sind .

 

[Heinileini]

Die alten Programmierer können mit Datentypen meist besser umgehen als die jungen Programmierer.

Danke für die Blumen, Dieter.
Den alten Programmierern wurden aber auch oft so Speicherplatz-verschwendende "DatenTypen" wie "BCD" aufgedrängt. 16 Bit für 3 Stellen oder - sofern überhaupt verfügbar - 32 Bit für 7 Stellen. Negatives Vorzeichen möglich, aber irgendwie sehr lieblos und halbherzig.
Beim Laden von Zeitwerten in Timer und beim Vorbesetzen von Zählerständen in Zählern leider unverzichtbar, weil alternativlos.

Den "jungen Programmierern" werden heute DatentypKonvertierungen abverlangt, die sie nicht verstehen (können), weil sie nicht nah genug an die Bits herangelassen werden, um damit Erfahrungen zu sammeln und ein Verständnis dafür zu entwickeln.
Die "alten Programmierer" kannten die Wirkungsweisen (z.B. ZweierKomplement), aber sie brauchten die DatentypKonvertierungen nicht. Niemand brauchte sie und deshalb gab es sie auch nicht. Konvertierungen wie GRAY in DUAL oder DUAL erst in BCD und dann in ASCII, meine ich hiermit nicht. Auch nicht Ganzzahl in GleitKommaZahl.

Bei den S5-Steuerungen musste man wirklich noch mit dem Speicher geizen.

Oh ja, und wie!!! Ob man es schaffte, genügend Geiz in die Tat umzusetzen, das entschied oft genug darüber, ob die angestrebten Funktionalitäten überhaupt realisiert werden konnten.

 

[Blockmove]

@Heinileini
Du hast vollkommen recht.
Der sichere Umgang mit Datentypen und Zahlenformaten fehlt ganz vielen jungen SPSlern oder generell ITlern.
Sieht man regelmässig bei den Modbus-Fragen hier im Forum.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wobei man sich bei Siemens 1500 nicht sicher sein kann, dass ein SINT auch im Speicher nur ein Byte benötigt, und z.B. nicht zwei oder gar vier. Ein Bool benötigt hier auch ein Byte. Denn hier wird ja "optimiert", also der Programmierer muss sich hier eigentlich keine Gedanken mehr machen, weil immer alles "optimal" ist.

 

[Heinileini]

..., also der Programmierer muss sich hier eigentlich keine Gedanken mehr machen, weil immer alles "optimal" ist.

Hmmm. Weil immer alles "optimal" ist. Das klingt sehr sarkastisch und dürfte wohl auch so gemeint sein.
"Immer alles optimal" ist ein Widerspruch in sich. Man kann die Bedingungen so verschieben, dass mal der eine und mal der andere Aspekt optimal (quasi bevorzugt) berücksichtigt wird. Das ist alles eine Frage, wie man die einzelnen Aspekte jeweils bewertet/wichtet, um sie vergleichbar zu machen.
"Immer alles optimal" hört sich für mich an, wie "Nachtigall, ick hör dir trappsen".

Welche mehrehre Bytes belegende DatenTypen von der SpeicherplatzBeanspruchung her betrachtet, die sparsameren sind, kann man sich relativ leicht überlegen (mal abgesehen von irgendwelchen geheimnisvollen systembedingten "Optimierungen"). Welche "performanter" sind, wird man wohl testen müssen. Und dabei kann man durchaus Überraschungen erleben.
Gefühlsmässig wäre ich geneigt, die unsigned DatenTypen mit Vorsicht zu geniessen. Ich finde sie einfach von Hause aus zu "unnatürlich" für die üblichen Befehlssätze von Prozessoren.

 

[s_kraut]

Wobei man sich bei Siemens 1500 nicht sicher sein kann, dass ein SINT auch im Speicher nur ein Byte benötigt, und z.B. nicht zwei oder gar vier. Ein Bool benötigt hier auch ein Byte. Denn hier wird ja "optimiert", also der Programmierer muss sich hier eigentlich keine Gedanken mehr machen, weil immer alles "optimal" ist.

Ungünstige Vorzeichen wenn der Hersteller des Compilers auch der Hersteller der Speicherkarten ist

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Grundsätzlich habe ich kein Problem damit, dass der Compiler das alles auf den Prozessor hin optimiert. Das ist und war bei C schon immer so, dass ein Datentyp nur "mindestens" so groß sein muss. Da musste man sich bei kleinen Mikrocontrollern mit sehr begrenztem Speicher auch behelfen. Was nur nervt sind diese Nonsense-Bezeichnungen "optimiert" und "nicht optimiert", und dass sich das alles je nach Mondphase auch noch ändert.

 

[maxder2te]

Ich habe eine dumme Frage, hier gibt es nicht so viel los in Forum.

Ich sehe ganz oft, dass Datentyp INT in Programmen benutzt wird, sogar wenn da man benutzt die Zahlen von 0 bis 10, nicht mehr, z.B. bei CASE oder so.
INT ist 16 Bit, SINT ist 8 Bit.

Kann man anstatt INT doch SINT benutzen und ein bisschen Speicher in Programme sparen ? Oder da bringt grundsätzlich nix besonderes und/oder die Benutzung von INT hat irgendwelche eigene Vorteile?

Das kommt ein bisschen auf die Zielplattform an. Die heutigen Systeme (beispielsweise S7-1500 <= 1516) setzen ohnehin auf 32 Bit-Prozessoren, d.h. alles was am Prozessor selbst abläuft läuft ohnehin in 32 Bit Arithmetik ab. D.h. die Benutzung von INT oder SINT führt zwangsläufig zu Typecasts. Ganz extrem ist das beispielswiese auf Rockwell ControlLogix.
Das Thema Speicher sparen ist schon sinnvoll, aber wegen einzelne INT-Zugriffe st das nicht sinnvoll. Wenn man beispielsweise einen Datenstrom von 8k Daten verarbeitet macht es vielleicht einen Unterschied ob man SINT verwendet oder INT (oder CHAR statt WCHAR), aber ansonsten bleit der Speicherspareffekt unter der Wahrnehmbarkeitsgrenze.
Richtig sinnvoll wird das erst bei Schnittstellen, welche über parallele Datenkanäle übertragen werden, wie z.B. Profinet RT. Da kann es schn mal Sinn machen, dass man Zahlenwerte von 0-10 als u4, also als Unsigned INT mit 4 Bit Breite überträgt, speziell wen man 200 solcher Werte parallel übertragen will, aber ansonsten sollte man sich auf die Effezienz der verarbeitenden Prozessoren konzentrieren.

 

[ducati]

Ich habe eine dumme Frage, hier gibt es nicht so viel los in Forum.

Ich sehe ganz oft, dass Datentyp INT in Programmen benutzt wird, sogar wenn da man benutzt die Zahlen von 0 bis 10, nicht mehr, z.B. bei CASE oder so.
INT ist 16 Bit, SINT ist 8 Bit.

Kann man anstatt INT doch SINT benutzen und ein bisschen Speicher in Programme sparen ? Oder da bringt grundsätzlich nix besonderes und/oder die Benutzung von INT hat irgendwelche eigene Vorteile?

genausogut könnte man argumentieren, dass man doch immer DINT verwenden könnte, um nicht drüber nachdenken zu müssen, ob das jetzt wirklich immer alles reinpasst, wenn man anfängt damit zu rechnen oder man sich ausversehn vertan hat...

Also Diskussionen über Programmierstrategien enden meist im Sinnlosen.

 

[maxder2te]

Zuviel Werbung?
-> Hier kostenlos registrieren

genausogut könnte man argumentieren, dass man doch immer DINT verwenden könnte, um nicht drüber nachdenken zu müssen, ob das jetzt wirklich immer alles reinpasst, wenn man anfängt damit zu rechnen oder man sich ausversehn vertan hat...

Also Diskussionen über Programmierstrategien enden meist im Sinnlosen.

Rein aus der Praxis heraus ist das aber gar nicht so abwegig.

Ich hab mal ein umfangreicheres Paket von S7-1500 auf Rockwell 1756-L7 portiert und die Zykluszeit der Steuerung war recht mies. Bin dann nach Handbuchstudium drauf gekommen, dass die Rockwell-Controller intern ausschließlich mit Boll, DINT und REAL arbeiten. D.h. alles andere wird typsicher auf den höchsten vorkommenden Typen gecastet. Aufgrund der Typensicherheit sind die Casts sehr laufzeitintensiv.

Hab dann alles von SINT und INT auf DINT umgestellt und die Zykluszeit ging um ein Viertel runter........