Wie nennt man den Punkt

**BUG**

Wenn ich dir einen guten Link zum Compilerbau geben würde, würdest du dann einen bauen, und als Projekt in die DP stellen?

Nein

Aber den Link hätte ich trotzdem gerne, guten Lesestoff soll man ja nicht verweigern.

EDIT: Gerade in einer C++ Referenz gelesen: Elementoperator

**implementation**

Zitat von BUG:

Aber den Link hätte ich trotzdem gerne, guten Lesestoff soll man ja nicht verweigern.

Let's Build a Compiler! von Jack W. Crenshaw fand ich sehr gut, gerade weil das Einlesen von Ausdrücken so schön leicht erklärt wird.
Vielleicht entscheidest du dich ja noch um und baust uns doch einen

**himitsu**

Ein steuerbarer Precompiler für Delphi wäre mal was

Zitat:

Ein steuerbarer Precompiler für Delphi wäre mal was

Für was denn z.B.?

**himitsu**

Um sich die Syntax anzupassen, bzw. zu erweitern, Compilerfehler zu umgehen,
für Makros und andere Spielereien, wie z.B __FILE__ und __LINE__.

Und steuerbar, damit jeder dafür "Plugins" schreiben kann.

**Memnarch**

Danke für den Artikel, interressant zu lesen. Vllt was für meinen precomputer für LiteC

(auch wenn ich dabei bei plaintext bleibe und nicht mit assembler hantiere^^).

Aber:

Zitat:

There is a message here: code generated by our parser is less
efficient than the code we would write by hand. Get used to it.
That's going to be true throughout this series. It's true of all
compilers to some extent. Computer scientists have devoted whole
lifetimes to the issue of code optimization, and there are indeed
things that can be done to improve the quality of code output.
Some compilers do quite well, but there is a heavy price to pay
in complexity, and it's a losing battle anyway ... there will
probably never come a time when a good assembler-language pro-
grammer can't out-program a compiler.

DAs hat sich ja wohl inzwischen erledigt

MFG
Memnarch

Naja, nicht unbedingt. Ein absoluter ASM-Meister (und nicht der "Durchschnitts"-ASM-Progger) wird auch immer noch einen Compiler übertreffen, was die Performance angeht.
Es geht ja soviel ich verstanden habe nur um Performance. Nicht um Wartbarkeit oder dergleichen.

**Memnarch**

@Blackfin: Ok, stimmt schon. Wer ASM gut kann und wenn der Code auch noch SSE etc optimierungen begünstigt, ist natürlich klar wer gewinnt^^

Wie nennt man den Punkt

AW: Wie nennt man den Punkt

AW: Wie nennt man den Punkt

AW: Wie nennt man den Punkt

AW: Wie nennt man den Punkt

AW: Wie nennt man den Punkt

AW: Wie nennt man den Punkt

AW: Wie nennt man den Punkt

AW: Wie nennt man den Punkt

Forumregeln

himitsu Registriert seit: 11. Okt 2003 Ort: Elbflorenz 44.557 Beiträge Delphi 12 Athens	#3 AW: Wie nennt man den Punkt 17. Jun 2011, 07:48 Ein steuerbarer Precompiler für Delphi wäre mal was Ein Therapeut entspricht 1024 Gigapeut.
	Zitat

blackfin (Gast) n/a Beiträge	#4 AW: Wie nennt man den Punkt 17. Jun 2011, 08:31 Zitat: Ein steuerbarer Precompiler für Delphi wäre mal was Für was denn z.B.?
	Zitat

himitsu Registriert seit: 11. Okt 2003 Ort: Elbflorenz 44.557 Beiträge Delphi 12 Athens	#5 AW: Wie nennt man den Punkt 17. Jun 2011, 08:42 Um sich die Syntax anzupassen, bzw. zu erweitern, Compilerfehler zu umgehen, für Makros und andere Spielereien, wie z.B __FILE__ und __LINE__. Und steuerbar, damit jeder dafür "Plugins" schreiben kann. Ein Therapeut entspricht 1024 Gigapeut.
	Zitat

blackfin (Gast) n/a Beiträge	#7 AW: Wie nennt man den Punkt 17. Jun 2011, 09:00 Naja, nicht unbedingt. Ein absoluter ASM-Meister (und nicht der "Durchschnitts"-ASM-Progger) wird auch immer noch einen Compiler übertreffen, was die Performance angeht. Es geht ja soviel ich verstanden habe nur um Performance. Nicht um Wartbarkeit oder dergleichen.
	Zitat

Memnarch Registriert seit: 24. Sep 2010 737 Beiträge	#8 AW: Wie nennt man den Punkt 17. Jun 2011, 09:16 @Blackfin: Ok, stimmt schon. Wer ASM gut kann und wenn der Code auch noch SSE etc optimierungen begünstigt, ist natürlich klar wer gewinnt^^ Da man Trunc nicht auf einen Integer anwenden kann, muss dieser zuerst in eine Float kopiert werden
	Zitat