Kleine Integer?
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ß. |
Re: Kleine Integer?
Kannst dir doch nen eigenen machen
Delphi-Quellcode:
type
TMyInt = [-6..6]; var MyInt = TMyInt; |
Re: Kleine Integer?
Hallo,
geeignet wäre da ShortInt (-128..127). Du kannst Dir aber auch einen eigenen Typ deklarieren:
Delphi-Quellcode:
Gruß
type
TMyInt = -6..6; xaromz |
Re: Kleine Integer?
Shortint von -128..127
Einen Vorteil gegenüber Integer bringt das aber nicht. |
Re: Kleine Integer?
Doch. Wenn er ihn abspeichern will, kostet das weniger Speicher.
|
Re: Kleine Integer?
Eben nicht. Integer ist da die kleinste Einheit. Weniger Speicher als die generischen Typen geht nicht.
|
Re: Kleine Integer?
Liste der Anhänge anzeigen (Anzahl: 1)
hier ein auszug aus der d20006 hilfe:
|
Re: Kleine Integer?
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. |
Re: Kleine Integer?
Zitat:
|
Re: Kleine Integer?
Ach so. Aber sonst wäre die Hilfe ja auch noch schlechter geworden, was eigentlich kaum geht.
|
Re: Kleine Integer?
Hallo,
Zitat:
Gruß xaromz |
Re: Kleine Integer?
Genau dieses "Aufblasen" ist es. Aktuelle CPUs verarbeiten 32 Bit (oder bereits 64 Bit) und nicht 8 Bit.
|
Re: Kleine Integer?
Hallo,
Zitat:
Gruß xaromz |
Re: Kleine Integer?
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. |
Re: Kleine Integer?
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 |
Re: Kleine Integer?
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.
|
Re: Kleine Integer?
Hallo,
Zitat:
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 |
Re: Kleine Integer?
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? |
Re: Kleine Integer?
Hallo,
Zitat:
Gruß xaromz |
Re: Kleine Integer?
@himitsu: Wie wird denn ein einzelnes Byte gespeichert?
|
Re: Kleine Integer?
Ich meinte vorher mit weniger Speicher folgendes: Auf der Festplatte verbraucht es weniger Speicher, wenn er es in ne Datei schreibt.
|
Re: Kleine Integer?
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:
|
Re: Kleine Integer?
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 |
Re: Kleine Integer?
Hallo,
Zitat:
Gruß xaromz |
Re: Kleine Integer?
Zitat:
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. |
Re: Kleine Integer?
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. |
Re: Kleine Integer?
Zitat:
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: |
Re: Kleine Integer?
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.
|
Re: Kleine Integer?
Zitat:
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. |
Re: Kleine Integer?
Liste der Anhänge anzeigen (Anzahl: 2)
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" |
Re: Kleine Integer?
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.
|
Re: Kleine Integer?
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 |
Re: Kleine Integer?
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) |
Re: Kleine Integer?
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. |
Re: Kleine Integer?
Zitat:
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 |
Re: Kleine Integer?
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. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 00:30 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz