Kleine Integer?

[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 Also ich finds interessant, auch wenn ich nicht umbedingt alles verstehe

Mfg

[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 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.