Wie optimiert der Compiler?

[saft6luck]

Wie optimiert denn der Compiler folgende convert()-Konstrukte:

[highlight=epc]
CF_SendBuffer=$$c2000
CR_SendBuffer_temp=convert($$,CF_SendBuffer);

if (No_Client > convert(0,CF_No_Clients)) then ...
[/highlight]

Erkennt der Compiler, dass es sich hier um Konstanten handelt, deren Typ zum Kompilierzeitpunkt bekannt ist?

Falls nein, verursacht dies im 2. Fall bei jeder Ausführung eine Konvertierung und wieviel Speicher wird von diesen Konstanten $$ und 0 dann belegt?

[enertegus]

Erkennt der Compiler, dass es sich hier um Konstanten handelt, deren Typ zum Kompilierzeitpunkt bekannt ist?

Nein, aber: Wenn sich da nix ändert, dann wird die Funktion nicht ausgeführt (Validierung) und der letzt berechnete Wert zurückgegeben.

[saft6luck]

Nein, aber: Wenn sich da nix ändert, dann wird die Funktion nicht ausgeführt (Validierung) und der letzt berechnete Wert zurückgegeben.

Wie viel Speicher belegen dann die Werte?

Ich möchte den Typ der Variable durch die Initialisierung vorgeben -> der restliche Code soll sich automatisch daran anpassen.

Dafür muss aber convert() verwendet werden, siehe Beispiel.

Dies gilt dann für alle Typen, nicht nur für Strings. Also auch a=a+1, denn bei a=0u08 muss die Konstante 1 auch vom Typ u08 sein, falls a aber u16 wird, muss 1u16 verwendet werden.

Es ist also wichtig, ob ich im restlichen Code alle Konstanten dann ohne viel Speicherplatzverbrauch per convert() konvertieren kann, oder ich wegen des zusätzlichen notwendigen Speichers den Code umschreiben muss.

[enertegus]

Wie viel Speicher belegen dann die Werte?

Bezieht sich die Frage auf convert? Convert hat zwei "Eingänge" und einen Ausgang. Wieviel das in Byte ausmacht, hm... wohl Faktor 2...3 als das Ursprungsobjekt.

[saft6luck]

Bezieht sich die Frage auf convert? Convert hat zwei "Eingänge" und einen Ausgang. Wieviel das in Byte ausmacht, hm... wohl Faktor 2...3 als das Ursprungsobjekt.

Ist das statischer Speicher oder dynamischer und was macht das im konkreten Fall an Bedarf aus?

[highlight=epc]
CF_SendBuffer=$$c14
CR_SendBuffer_temp=convert(GA,CF_SendBuffer)+conve rt($+$,CF_SendBuffer);
[/highlight]

CF_SendBuffer belegt immer 14 bytes.
CR_SendBuffer_temp wird auch immer 14 bytes belegen, oder?

Wird das rechte convert() dann auch einen String von 14 bytes erzeugen und das Ergebnis in CR_SendBuffer_temp kopieren?

Und wird es das bei jeder Änderung der GA gemacht?
(Auch wenn der Wert der Parameter sich nicht ändert, der String muss ja dann trotzdem zumindest als Ergebnis vorhanden sein)

Selbiges Beispiel mit anderem Typ:

[highlight=epc]
CF_SendBuffer=$$c1400
CR_SendBuffer_temp=convert(GA,CF_SendBuffer)+conve rt($+$,CF_SendBuffer);
[/highlight]

Wie sieht es hier aus?

[enertegus]

Ist das statischer Speicher oder dynamischer und was macht das im konkreten Fall an Bedarf aus?

statisch

Wird das rechte convert() dann auch einen String von 14 bytes erzeugen und das Ergebnis in CR_SendBuffer_temp kopieren?

Ja, wobei ein Stringobjekt neben den Daten noch weitere Objektspeicher für die Verarbeitung (Funktionszeiger, Objekteigenschaften ...) benötigt. Daher sind es sicher mehr als 14 Byte pro Objekt.

Und wird es das bei jeder Änderung der GA gemacht?

Ja.

Wie sieht es hier aus?

Stringgröße plus Objektoffset.

[saft6luck]

Das kling so, als wäre es keine gute Idee über convert() eine Typabhängigkeit aufzulösen.

Schade, dass es hierfür auch keine Makros gibt.