Anregungen und Vorschläge zu PROFAN
Hier können Vorschläge für künftige PROFAN-Versionen, Ausgestaltung der PROFAN-Seiten und -Foren, etc. gemacht werden.

| Suchen
| Zurück zur Übersicht

Autor | Thema: Direkte einbindung für assambler
Daniel Koch
| Datum:06.08.01 16:04 (koch@pmia.de) |
Profan is ja bei 3D anwendungen echt richtig schnell am ende, wenn die ports offen währen könnt man sich den grafik krams selber schreiben oder, wenigstens anbindungen an den ganzen open GL krams, wär nicht schlecht. gruß Daniel Koch
Frank Abbing
| Datum:06.08.01 20:08 (frankabbing@12move.de) |
Ich bin dafür, selbst wenn das Interpreter/Compiler Schema dafür aufgegeben werden müßte. Würde den Code auch wesentlich (!) schlanker und schneller machen. Eigentlich nur Vorteile, aber auch auch 'ne Masse Arbeit... Frank
Sven Schmidts
| Datum:07.08.01 13:47 (schmidts@flat2serv.de) |
Hallo, ist nicht möglich. ASM müsste sonst interpretiert so werden, wie jeder andere Code von Profan² auch. Wenn sich im CBuilder- oder im Delphi- Code ein Assembler-Teil befindet, dann braucht dieser vom Compiler nicht mehr übersetzt werden, weil er bereits in ASM vorhanden ist. Jeder andere Teile wird übersetzt. Da Profan² kein Nativ-Code (und damit kein ASM) erzeugen kann, würde ASM auch nur als Interpreter laufen und somit "nur" eine Befehlserweiterung darstellen. Das Problem (wie Geschwindigkeit, Callback etc.) liegt am P-Code ... man müsste also den Compiler von Grund auf neu bauen und in "Nativ" machen. Dann aber würde ASM auch keinen nennenswerten Vorteil bringen. Mfg. Sven Schmidts
Frank Abbing
| Datum:07.08.01 19:59 (frankabbing@12move.de) |
Hallo, Profan mit einem richtigen Compiler, der den Code sofort in Maschinensprache umsetzt, das meinte ich ja ebenfalls. Direkte Assemblerprogrammierung ist immer noch wesentlich schneller und kürzer als z.B. ein C-Compilat. Bestes Beispiel: Ich erzeuge eine leere DLL mit C++, Anzahl Bytes der Dll: minimum 49152 Bytes. Das gleiche in Assembler, minimum 1024 Bytes !!! Das ist ein Faktor von 48. Der C-Compiler hat viel Schrott produziert, der gar nicht benötigt wird, also viel zu viel Code und somit viel zu viel Powerverlust. Meine ProSpeedDLL z.B. hat jetzt 52 Funktionen, ist aber nur um die 16000 Bytes groß. Ein Native-Compiler kann niemals einen gut programmierten Assemblercode ersetzten, auch wenn das immer wieder behauptet wird. Mein Rat an Roland, auf Dauer kommst du gar nicht darum herum, also kannst du schon jetzt mit einem neuen (richtigen) Compiler beginnen, dann kann auch jeder mit Profan DLL's programmieren und schnelle Programme coden. Ich schätze, eine neue Profanversion, die 1000 mal schneller ist als die alte, würde sich ganz sicher sehr toll verkaufen lassen. Bis dahin, Frank
Sven Schmidts
| Datum:07.08.01 20:05 (schmidts@flat2serv.de) |
Hallo Frank, in einigen Punkten hast Du recht. Da aber eine Anwendung aus ein wenig mehr als Speicher-Funktionen besteht, benötigt ein Compiler mehr funktionalität. Um es im Klartext zu schreiben: Versuche einmal, die gesamte Profan² Funktionalität in Assembler abzubilden ... viel Spass. Und wenn es um das Objekt-Management geht dann bietet die VCL grundlegende Vorteile. Nicht umsonst werden "nur" geschwindigkeitsrelevante Routinen in Assembler ausgelagert, der Rest kommt dann unter eine VCL Haube (oder MFC, je nachdem). Wie dem auch sei wird es schwer, Profan² einen "echten" Compiler zu gönnen. :) Mfg. Sven Schmidts
Frank Abbing
| Datum: 08.08.01 08:42 (frankabbing@12move.de) |
Hallo, da geb' ich dir recht, komplette Programme in ASM zuschreiben ist fast unzumutbar, obwohl, gemacht hab' ich das schon... Mal sehen, was Roland daraus macht... Frank

| Zurück zur Übersicht

| Ein kostenloses WebMart Forum WebMart Homepage Tools kostenlos |