Kleine Integer?

[xZise]

Ich benötigte eine Ganzzahl im Zahlenraum von 6 - (-6).

Welcher Zahlentyp ist dafür am besten geeignet?
Byte kann keine negativen Zahlen und Integer ist ein bisschen groß.

[NicNacMan]

Kannst dir doch nen eigenen machen

Delphi-Quellcode:

type
  TMyInt = [-6..6];

var
  MyInt = TMyInt;

[xaromz]

Hallo,

geeignet wäre da ShortInt (-128..127). Du kannst Dir aber auch einen eigenen Typ deklarieren:

Delphi-Quellcode:

type
  TMyInt = -6..6;

Gruß
xaromz

[Ydobon]

Shortint von -128..127
Einen Vorteil gegenüber Integer bringt das aber nicht.

[3_of_8]

Doch. Wenn er ihn abspeichern will, kostet das weniger Speicher.

[Ydobon]

Eben nicht. Integer ist da die kleinste Einheit. Weniger Speicher als die generischen Typen geht nicht.

[semo]

hier ein auszug aus der d20006 hilfe:

[Ydobon]

Bei D 2005 war das immerhin noch in Deutsch. :?:

Abgesehen davon, es gibt keinen Typ, der an der Verarbeitungsbreite der CPU vorbei kommt. Die ist zz. nun einmal meist 32 Bit = Integer oder Cardinal. Alles andere wird genau mit diesen Werten gespeichert, nur das Laufzeitsystem hat dann mehr Arbeit mit der Typenprüfung.

[semo]

Zitat:

Bei D 2005 war das immerhin noch in Deutsch.

kommt halt drauf an welche version man nutzt :wink:

[Ydobon]

Ach so. Aber sonst wäre die Hilfe ja auch noch schlechter geworden, was eigentlich kaum geht.

[xaromz]

Hallo,

Zitat:

Zitat von Ydobon

Abgesehen davon, es gibt keinen Typ, der an der Verarbeitungsbreite der CPU vorbei kommt. Die ist zz. nun einmal meist 32 Bit = Integer oder Cardinal. Alles andere wird genau mit diesen Werten gespeichert, nur das Laufzeitsystem hat dann mehr Arbeit mit der Typenprüfung.

Wie kommst Du denn darauf? Klar kann ich ein Byte auch als Byte im Speicher ablegen und die CPU verarbeitet das dann auch als Byte. Ob die CPU das Byte intern wieder "aufbläst" ist egal, aber auch unwahrscheinlich, weil sonst manche Befehle nicht mehr funktionieren würden (z. B. ROL, ROR).

Gruß
xaromz

[Ydobon]

Genau dieses "Aufblasen" ist es. Aktuelle CPUs verarbeiten 32 Bit (oder bereits 64 Bit) und nicht 8 Bit.

[xaromz]

Hallo,

Zitat:

Zitat von Ydobon

Genau dieses "Aufblasen" ist es. Aktuelle CPUs verarbeiten 32 Bit (oder bereis 64 Bit) und nicht 8 Bit.

Hast Du da 'nen Link oder so was? Das würde mich schon interessieren, wie eine CPU z. B. die Bit-Rotation dann umsetzt.

Gruß
xaromz

[Ydobon]

Einfach mit Nullen auffüllen? Den Rest muss dann etwas anderes (natürlich mit Geschwindigkeitsverlust) machen. Wenn die CPU halt nichts kleiner als 32 Bit adressieren kann, gibt es kein Byte mehr.

Sorry, aber ich habe keinen Link.
Da ich mit 8-Bit Prozessoren angefangen und deren Entwicklung beobachtet habe, hatte ich aus meiner Beobachtung gefolgert, dass andere genauso urteilen werden.

[himitsu]

8 BitRotation?

in 'nem 8-Bit-Register natürlich :zwinker:

z.B.
EAX = 32 Bit
AX = 16 Bit
AL und AH = 8 Bit

in der CPU sind die dann üperlappend gespeichert:

Code:

3322222222221111111111
10987654321098765432109876543210
******************************** EAX
                **************** AX
                        ******** AL
                ********         AH

[Oxmyx]

Ohne zwingenden Grund (z.B. Dateizugriffe) halte ich es für sinnlos, einen anderen ganzzahligen Datentyp als Integer zu verwenden. Die vier Bytes Speicher machen niemandem was aus.

[xaromz]

Hallo,

Zitat:

Zitat von himitsu

8 BitRotation?

in 'nem 8-Bit-Register natürlich :zwinker:

z.B.
EAX = 32 Bit
AX = 16 Bit
AL und AH = 8 Bit

Danke, ich spreche fließend Assembler und kenne mich auch mit dem Aufbau aktueller CPUs recht gut aus.
Das ist ja genau mein Problem: Wenn es Byte-Register gibt, wie und wozu bläst dann die CPU ein Byte auf 32 Bit auf (wie behauptet)? Das erscheint mir nicht wirklich einleuchtend.

Gruß
xaromz

[himitsu]

wo bläßt sie den denn auf?

im RAM und sonstewo kann dennoch ein einzelnes Byte gespeichert werden, übertragen kann sie zwar nur 32 Bit, also auch alles größer als 32-Bit wird ebenfalls gesplittet, aber sonst?

[xaromz]

Hallo,

Zitat:

Zitat von himitsu

wo bläßt sie den denn auf?

im RAM und sonstewo kann dennoch ein einzelnes Byte gespeichert werden, übertragen kann sie zwar nur 32 Bit, also auch alles größer als
32-Bit wird ebenfalls gesplittet, aber sonst?

Diese Behauptung kam von Ydobon im Beitrag #12.

Gruß
xaromz

[Ydobon]

@himitsu: Wie wird denn ein einzelnes Byte gespeichert?

[3_of_8]

Ich meinte vorher mit weniger Speicher folgendes: Auf der Festplatte verbraucht es weniger Speicher, wenn er es in ne Datei schreibt.

[himitsu]

wie alle CPUs ganz genau arbeiten weiß ich doch auch nicht, aber IMHO muß ja nicht immer die gesamte Dateinbreite ausgenutzt werden ... wer sagt denn, daß die CPU icht mal nur 8, der 32 Datenleitungen verwenden muß?

Und wichtig ist doch wohl eigentlich nur, daß die CPU eben doch mit 8-Bit-Werten umgehen kann.

Zitat:

Zitat von 3_of_8

Ich meinte vorher mit weniger Speicher folgendes: Auf der Festplatte verbraucht es weniger Speicher, wenn er es in ne Datei schreibt.

Jo, das sollte wohl klar sein, denn sonnst könnte ich meine gepackten Records an die Wand schmeißen -.-''

[marabu]

Hallo Leute,

selbstverständlich addressiert eine Intel CPU mit einem 32-bit Datenbus auch Bytes. Darüber hinaus kann jedes general purpose register als 8-bit, 16-bit oder 32-bit Register adressiert werden. Das Grundstudium Informatik umfasst (zumindest zu meiner Zeit) auch Kurse der technischen Informatik, in denen man den Aufbau eines solchen Registers lernt. Das einzige was nicht geht ist das Laden der oberen 16 bit ohne Zerstörung der unteren 16 - wenn ich mich richtig erinnere.

Grüße vom marabu

[xaromz]

Hallo,

Zitat:

Zitat von marabu

Das einzige was nicht geht ist das Laden der oberen 16 bit ohne Zerstörung der unteren 16 - wenn ich mich richtig erinnere.

Zumindest nicht mit einem Move, da braucht man min. drei Befehle (rotate, move, rotate).

Gruß
xaromz

[3_of_8]

Zitat:

Zitat von 3_of_8

Ich meinte vorher mit weniger Speicher folgendes: Auf der Festplatte verbraucht es weniger Speicher, wenn er es in ne Datei schreibt.

Jo, das sollte wohl klar sein, denn sonnst könnte ich meine gepackten Records an die Wand schmeißen -.-''[/quote]

Natürlich sollte das wohl klar sein. Meine Aussage vorher brachte ich nur, um die Aussage, <32 Bit Datentypen hätten keine Vorteile, zu widerlegen.

[Sidorion]

Jetzt geb ich doch auch mal meinen Senf dazu:
Jede Speicherzelle (zumindest bei x86 Systemen) ist exakt 8 bit groß.
Bei einem Speicherzugriff kann (je nach Datenbusbreite, das mach dann der Controller) man entweder 8, 16 oder 32 Bit lesen, da die Zellen heutzutage in 4er Gruppen angelegt sind. Wenn ich also 4 byte aus dem Speicher holen will, brauche ich entweder einen Zyklus (lesen eines Integers), zwei Zyklen (Lesen von zwei words) oder vier Zyklen (Lesen von 4 Bytes).
Sicher spart man durch Verwendung vo kurzen Datentypen Speicher, aber die Geschwindigkeit leidet, wenn man nicht den Datentyp nimmt, der der Busbreite entspricht. Da heutzutage der Speicher relativ uninteressant ist, kann man durchaus ohne Bedenken mit Integer arbeiten.
In der CPU ist es übrigens völlig Wurscht, welchen Typ ihr nehmt. Die CPU bietet Befehle für die Manipulation aller drei Varianten (ber 64Bittern dann vier), die sich in der Geschwindigkeit nicht nterscheiden.

[Nicolai1234]

Zitat:

Zitat von 3_of_8

Zitat:

Zitat von 3_of_8

Ich meinte vorher mit weniger Speicher folgendes: Auf der Festplatte verbraucht es weniger Speicher, wenn er es in ne Datei schreibt.

Jo, das sollte wohl klar sein, denn sonnst könnte ich meine gepackten Records an die Wand schmeißen -.-''

Natürlich sollte das wohl klar sein. Meine Aussage vorher brachte ich nur, um die Aussage, <32 Bit Datentypen hätten keine Vorteile, zu widerlegen.[/quote]
Kommt doch daraud an, wie man speichert, oder? :oops:

Ob ich ein Integer, ein Int64 oder gar ein String mit dem Inhalt 1 / "1" in beisielsweise einer ini speichere, nimmt das doch immer denselben Platz auf der Festplatte weg, oder? :oops: Sorry, aber wahrscheinlich kenn ich mich nicht aus und bin zu naiv :roll:

[3_of_8]

Wer redet denn von ner INI? In ner INI wird das keinen Unterschied machen, aber da wird das ja auch nicht als Ordinaltyp, sondern als String gespeichert. Wenn man das in nen Record schmeißt oder per FileStream speichert, wird weniger Platz verbraucht.

[Phoenix]

Zitat:

Zitat von Nicolai1605

Ob ich ein Integer, ein Int64 oder gar ein String mit dem Inhalt 1 / "1" in beisielsweise einer ini speichere, nimmt das doch immer denselben Platz auf der Festplatte weg, oder?

Bei einer 1 ja. Klaro. Nämlich jeweils genau 1 Byte.
Aber ne 1 könnte ich Dir auf der Platte auch ideal mit genau einem Bit ablegen - aber dann halt nicht in einer Ini-Datei.

Aber um es mal so zu sagen: Ob das nun in einem ShortInt oder in einem Int abgelegt wird ist für die Verarbeitungsgeschwindigkeit unerheblich, das der Int genauso in einem Zyklus behandelt werden kann (bei 64bit CPU's wäre das sogar ein Int64). Auf der Platte oder im Speicher kann man den Unterschied auch erst dann merken, wenn die Anzahl der so zu speichernden Werte eine nicht unerhebliche Größe erreicht. Wenn der Wert nur 10-20 mal gespeichert werden muss isses also im Prinzip egal, die paar Byte kann jeder verkraften. Bei mehreren tausend Datensätzen ist das dann schon spürbarer.

[Michael Habbe]

Wie der Speicherverbrauch der Datentypen innerhalb der CPU aussieht kann ich nicht sagen, da müsste sich mal jemand zu äußern, der sich da auskennt.

Auf alle Fälle ist der Speicherverbrauch auf dem Datenträger nur so groß, wie der Datentyp auch benötigt.

Wieder mal ein fertiges Beispiel aus der Vorlesung :wink:
Die oberen Memos sind für die Anzeige der Datei, wenn diese auf verschiedene Art gelesen wird. Zuvor muss sie aber erstellt werden.

Der Zweck dieses Programmes sollte sein, zu zeigen, das es egal ist, wie ich eine Datei erstelle. Wichtig ist nur, das ich sie auch im selben Format auslese und mich nicht im Datentyp vertue. Dieses (einfache) Beispiel ist natürlich auch auf selbstdefinierte Datentypen übertragbar, als da seinen z.B. File of "Record"

[3_of_8]

Innerhalb der CPU hast du nur ein paar Register. Der Speicherverbrauch dort ist absolut egal, da man nach ein paar Arbeitsschritten sowieso alles in den RAM speichert.

[xZise]

So... Der Threadersteller meldet sich auch mal zu Wort:
Eigentlich geht es nur darum, dass ich eigentlich immer "passende" Datentype verwende.
d.h. wenn ich weiß das ein Wert zwischen 40 und 78 zum Beispiel liegt, und es eine Ganzzahl ist, dann werde ich ihn immer als Byte deklarieren... Und deshalb habe ich gefragt ^^, weil ich sozusagen umbedingt einen Byte wollte, mit Vorzeichen (ShortInt).

Aber ihr könnt ruhig weiterdiskutieren :mrgreen: Also ich finds interessant, auch wenn ich nicht umbedingt alles verstehe :cyclops:

Mfg :D

[Christian Seehase]

Moin Fabian,

da der Compiler die Daten i.d.R. auf 32-Bit Grenzen ausrichtet verbraucht ein Byte allerdings trotzdem 4-Byte Speicher.
(wenn ich mal von packed record absehe)

[Sidorion]

Das tut er nur in einem Record für den schnelleren Zugriff, da er hier nicht erst den Typen der vorherigen Member prüfen muss, um den Offset zu berechnen.
Abgesehen davon legt er ein Byte in eine Speicheradresse, das nächste in die nächste. Bei Word versucht er, eine geradzahlige Speicherzelle zu nehmen (wegen Zugriff, siehe letztn Post), da er den Wert dann in einem Zugriffszyklus laden kann. Bei Integer(int32) nimmt er dann eine Zelle mit durch 4 teilbaren Adresse (selber Grund).
d.h. Du verlierst nur dann Speicher wenn Du abwechselnt Byte und Integer speicherst.

Speicherzellen sind nach wie vor 8 Bit groß, nur der Datenbus ist 32Bit breit, was Dazu führt dass er bis zu 4 Zellen gleichzeitig auslesen kann.

[Der_Unwissende]

Zitat:

Zitat von xZise

Eigentlich geht es nur darum, dass ich eigentlich immer "passende" Datentype verwende.

Hi,
stellt sich für mich die Frage: Warum?
Hab gerade die Delphi-Hilfe nicht zur Hand, aber schau da mal unter Integer in die OH. Da steht sinngemäß, dass du immer Integer oder Cardinal verwenden solltest, wenn du einen solchen Typ brauchst. Ausnahmen sind natürlich Strukturen, die zu etwas bestimmten (z.B. eine C Struct) kompatibel sein müssen.
Jedenfalls lohnt sich der 3 Byte unterschied nicht, hier auf ShortInt zu setzen.

Zwei Sachen wurden hier schon völlig richtig gesagt, den Speicher hast du locker und es möglich Bytes auch einzeln zu addresieren. Die Frage von Vor- und Nachteilen wird ja noch halbwegs diskutiert.
Mir ist nicht ganz klar, wie Leute hier wirklich eine Aussage über die Ausführungsgeschwindigkeit machen wollen. Ob ein Register mit 0en aufgefüllt wird oder nicht, dass liegt nicht in der Hand des Programmierers. Die Jungs von AMD, Intel, Transmeta, IBM, ... entscheiden das für einen. Der Assembler ist letztlich (trotz seiner Hardwarenähe) sehr abstrakt. Man hat einen Befehl mit gewissen Argumenten und bekommt das erwartete Ergebnis, was dazwischen passiert ist eigentlich Sache der CPU. Mag sein, dass sich einige sehr intensiv mit den heutigen Systemen beschäftigt haben (gibt ja ein paar ordentliche bekannte Fakten), aber schon über die nächste Generation kann man nicht mehr eine sichere Aussage treffen (oder man sollte sich schnell einen Job bei einem der Großen suchen!).
So wird man sicherlich weiterhin die Adressierung auch Byte-Weise erlauben. Doch ob bei Addition eine ALU wirklich nach 8 Bit abbricht oder ob sie (was sehr viel wahrscheinlicher ist) einfach alle 32 Bit nahezu parallel berechnet und dann die Überträge mit einbezieht, dass ist das Geheimnis der CPU. Gerade bei den Arithmetischen Operationen wird einiges getan um die Konkurrenz zu übertreffen. Alles was auf einer CPU gemacht wird ist so komplex, dass es wohl nichts für das mal ebend anschauen und verstehen ist. Und letztlich wird keiner der Hersteller die letzten Kniffe und Tricks preisgeben wollen (das ist ihr jeweiliges Kapital!)

Wenn du also irgendeine Operation mit deinen Variablen ausführst, dann kann es gut sein, dass die Werte bevor sie an die ALU gehen mit 0en aufgefüllt sein müssen. Das würde dann etwas Zeit kosten. Die Wahrscheinlichkeit, dass sich diese Nanosekunden auf addieren in einen Bereich den du merkst, ist 0. Dazu finden viel zu wahrscheinlich häufiger Zugriffe auf den Cache und vielleicht sogar auf RAM oder noch schlimmer anderen Speicher (Festplatte, CD-ROM, USB-Stick,...) statt. Diese sind dann um einiges Größer und dominieren selbst häufiges füllen mit 0en total.

Trotzdem lohnt es sich einfach nicht, mit einem so beschränkten Typen zu arbeiten. Ich denke Borland hat seine Gründe, warum eine Empfehlung ausgesprochen wird und im Zweifel sollte man sich ruhig an die halten.

Gruß Der Unwissende

[Sidorion]

Es werden keine Register mit nullen aufgefüllt! Wo kämen wir denn da hin?????? das wäre ja tödlich für die Register, wenn eine simple Addition des LowByes das HighByte einfach nullen würde.
Abhängig vom Befehl (es gibt Varianten für ..L, ..H, ..X, E..X) werden nur bestimmte 'Schieber', die vom Register an die ALU gehen geöffnet (eben Schieber für LowByte, HighByte ..). Die restlichen Bits kommen AUTOMATISCH als 0 an. Die ALU rechnet dann mit der vollen Breite und bei der Rückgabe werden wieder nur die entsprechenden Schieber geöffnet, um den Low-, High-, wasauchimmer-Teil des Ergebnisses wieder in das Register zurückzuschieben.
Die Flags für Übertrag, Sign, Zero, usw. werden auch grundsätzlich gesetzt (natürlich wieder abhängig vom Befehl: mit übertrag/ohne Übertrag sind zwei versch. CPU-Befehle).
In der Tat unterscheiden sich die Befehle in der ALU durch nix, nada, niente, rien, nihil, nothing.