Makro-Ersatz

[FAlter]

Hi,

wie kann ich ungefähr sowas realisieren, wo Delphi ja keine Makros kennt (ohne einen Präprozessor zu benutzen):

Delphi-Quellcode:

procedure foo;
var
  bar: Integer;

  procedure foo2; inline;
  begin
    inc(bar);  
  end;

begin
  ...
  foo2;
  ...
end;

Zitat:

[Pascal Fehler] foobar.pas(123): E2449 Verschachtelte Inline-Routine 'foo2' kann nicht auf Variable 'bar' außerhalb des Gültigkeitsbereichs zugreifen

Nun ja, ich könnte inline entfernen, aber da da nur inc drinsteht, ist das ein wenig überladen. Da der Name foo2 allerdings aussagekräftiger ist, möchte ich nicht direkt inc schreiben, zumal foo2 keinen Parameter verlangt. Mit Makros wäre mein Problem ja lösbar, einfach sirekt an der Stelle foo2 stattdessen inc(bar) einsetzen. Aber das macht Delphi nicht mit. An der Stelle, wo foo2 aufgerufen wird, gibt es kein anderes SP, damit sollte es also keine Probleme geben.

Gibt es also eine bessere Lösung als direkt inc(bar) reinzuschreiben oder nicht-inline-procs?

Mfg
FAlter

[Bernhard Geyer]

Ich würde erstmal bei Codegear einen enhancement-request im QC eintragen das solche Konstrukte auch als inline möglich wären. Ich würde einfach sagen das hier der Compiler einfach zu vorsichtig arbeitet.

[himitsu]

funktioniert INLINE überhaupt wieder?

Zitat:

Zitat von D7-OH

Das reservierte Wort inline und die Direktive assembler werden aus Gründen der Abwärtskompatibilität beibehalten. Sie haben keine Auswirkungen auf den Compiler.

nja, jedenfalls ohne das inline kann ich es porblemlos kompilieren/verwenden.

[FAlter]

Hi,

sowas steht in der Hilfe zu TurboDelphi nicht drin, im Gegenteil lässt sich herauslesen, dass es durchaus eine Funktion hat:

Zitat:

Beim Delphi-Compiler ermöglicht zur Verbesserung der Leistung, Funktionen und Prozeduren mit der Direktive inline zu versehen. Wenn eine Funktion oder Prozedur bestimmten Kriterien entspricht, fügt der Compiler Code direkt ein anstatt einen Aufruf zu generieren. Das Ergebnis dieser Leistungsoptimierung ist schnellerer Code, der jedoch mehr Speicherplatz in Anspruch nimmt. Der Compiler produziert dabei eine größere Binärdatei. Die Direktive inline wird in Funktions- und Prozedurdeklarationen und -definitionen, genau wie andere Direktiven, verwendet.

Weiter unten steht:

Zitat:

{$INLINE AUTO} Verhält sich wie {$INLINE ON}; zusätzlich werden Routinen ohne die Direktive inline für das Inlining vorgesehen, wenn ihr Code weniger oder genau 32 Bytes umfasst.

Werd mal probieren, was passiert, wenn ich in meinem Beispiel (was ja entsprechend klein sollte) [$INLINE AUTO} einfüge, wass die Assembler-Ansicht dann sagt.

[edit]

Die CPU-Ansicht sagt:

Code:

...
FooBar.pas.345: foo2;
...
00477F0E E809FFFFFF       call foo2;
...

Klappt also offensichtlich nicht.
[/edit]

Mfg
FAlter

[Hawkeye219]

Hallo himitsu,

Zitat:

Zitat von himitsu

funktioniert INLINE überhaupt wieder?

INLINE <> INLINE!

Zu Turbo-Pascal-Zeiten wurde das Schlüsselwort "INLINE" anfangs benötigt, um Maschinencode direkt in das Compilat einzuflechten. Einen eingebauten Assembler brachte erst Turbo Pascal 6.0 mit, wenn ich mich richtig erinnere. Der von dir zitierte Ausschnit aus der Online-Hilfe bezieht sich wohl auf diese ursprüngliche Verwendung.

Gruß Hawkeye

[FAlter]

Hi,

ich habe mich jetzt erstmal entschieden, foo2 auszukommentieren und weiter unten inc(bar){foo2} zu schreiben. Dann weiß ich erstmal, dass mit inc(bar) foo2 gemeint ist, und es hat den gewünschten Effekt, nämlich, dass nicht der Prozeduraufruf, sondern deren Code eingebaut wird. Schade, dass es nicht noch schöner geht (außer mit nem Präprozessor, aber TurboDelphi und IDE-Erweiterungen...).

Mfg
FAlter

[himitsu]

OK schön, dann geht dat ja wieder ^^

hast du es schonmal mit Assembler versucht?

Delphi-Quellcode:

procedure foo2; inline;
asm
  inc &bar
end;

@Hawkeye219
ich weiß, und das von dir zitierte INLINE funktioniert auch immernoch ... zumintestens in etwa :stupid:

Delphi-Quellcode:

{$L Dateiname}
{$LINK Dateiname}

für Pascalcode:

Delphi-Quellcode:

{$I Dateiname}
{$INCLUDE Dateiname}

aber ich bezog mich auf die Compilierdirektiven für Funktionen/Prozeduren

INLINE sagte (und sagt jetzt wieder), daß der Funktions-/Prozedurinhalt in den aufrufenden Code direkt eingebunden werden soll.
Nja und ASSEMBLER sagte dem Kompiler, daß er gleich eine ASM-Funktion vorfindet (find ich irgendwie sinnlos, weil das sollte der ja och so sehn, aber was solls)

[FAlter]

Hi,

laut OH vertragen sich inline und Assembler nicht. Auch bei Auto wird laut CPU-Fenster immer noch ein call ausgeführt.

Mfg
FAlter

[himitsu]

Zitat:

Zitat von FAlter

Auch bei Auto wird laut CPU-Fenster immer noch ein call ausgeführt.

Wenn ich das da oben richtig verstanden hab, dann schaut auto auch nur was möglich ist.
Un da es nicht geht wenn du explizit INLINE befiehlst, dann war's ja wohl klar daß die Automatik das auch nicht hinbekomm ._.

[alzaimar]

Wieso lässt du das 'inline' nicht einfach weg? Ich verwende lokale Prozeduren und Funktionen zuhauf. Es erhöht die Übersichtlichkeit enorm (wenn man es nicht übertreibt). Mir persönlich ist es fast immer egal, wenn dadurch ein paar Nanosekunden flöten gehen. Wichtiger sind Eigenschaften wie Übersichtlichkeit, Lesbarkeit, Wartbarkeit.

[FAlter]

Hi,

weil es sinnlos ist, eine Prozedur zu verwenden, wenn es nur um eine winzige Anweisung geht. So ein inc ist mit einer einzelnen Maschinenanweisung übersetzbar, dafür das ganze Register-auf-Stack-sichern, call, inc, ret, register-von-stack-holen, in meiner Schleife multipliziert sich die zusätzliche Verlangsamung. Die Übersichtlichkeit war gerade das Argument, weshalb ich es lieber inline hätte. Aber ohne inline verzichte ich lieber auf den overhead. In diesem Fall wäre inline sogar eine Speicherplatzersparnis, was es sonst meist nicht ist, denn inc verbraucht weniger Speicher als push, call, pop. Es sind also nicht ein paar vervielfachte Nanosekunden, sondern auch noch ein paar vervielfachte Bytes. Außerdem handelt es sich tatsächlich um zwei mini-Procs (die andere wäre dec) ind eine Funktion (bar > 0). Nochmal das ganze vervielfacht.

Wäre es komplexer, würde ich es dann wirklich auslagern. Durch Optimierung eines Problemes ist für foo2 jedoch nur noch das inc übriggeblieben, und da lohnt es sich nicht mehr, außer, man verwendet eben inline, was aber nicht geht. Nun kann man aber bei inc nicht erkennen, dass der eigentliche Hintergrund, was getan werden soll, foo2 ist. Ich will sozusagen den Namen foo2 für die Anweisung inc(bar) verwenden.

Weder die vielen Nanosekunden noch die Bytes sind ein Problem. Es geht eher ums Prinzip. Übersichtlichkeit und lesbarkeit leiden unter meiner Lösung mit dem Kommentar nicht wirklich, da es so kleine Änderungen sind. Und warten werde ich es wohl nie müssen, da im Dezember Abgabe des Projekts ist und ich dann nier wieder damit zu tun haben muss (Schulaufgabe). Aber mit sinnlos-procs hätte ich ein schlechtes Gewissen.

Mfg
FAlter

[alzaimar]

Ah, dann ist es klar. Ich dachte, das war ein Beispiel...