Perseus 2.6 - Caffeinated Cat

  • EDIT:
    alter kompilierter ASM code: 106 Zeilen (in diesem Post die obige Funktion)
    neuer kompilierter ASM code: 59 Zeilen (in diesem Post die untere Funktion)

    Geil :thumbup: . Schön, dass sich gleich einer damit befasst :D

    Ich glaube man kann keine void-Funktion machen

    Doch. void als Typ und nur return ohne Semikolon oder Wert.

    Windows 7 64 Bit.

    Diese Version von FASM ist eine 32bit Version. Du kannst höchstens versuchen die aktuelle FASM Version herunterzuladen und FASM.exe zu ersetzen, was aber imho keine Besserung bringen sollte. Vlt. blockt auch WinDefender / dein Antivirus FASM?

  • Spoiler anzeigen

    [Blockierte Grafik: http://i.epvpimg.com/AsZTb.png]

    Hm ja, da freue ich mich schon und es funktioniert nicht :huh:

    Was habe ich falsche gemacht? Windows 7 64 Bit.

    Grüße Njahs


    Habe auch Win7 64bit, anscheinend funkt dein Virenscanner dazwischen.
    Nachdem ich meinen gesamten Perseus-Ordner als Ausnahme bei avast hinzugefügt habe, ist alles wie am Schnürchen gelaufen.
    Kannst ja auch mal testweise dein AV aussschalten und nochmal probieren, wenns dann funktioniert, weißt ja worans liegt ;)

    There's a joke that C has the speed and efficieny of assembly language combined with readability of....assembly language. In other words, it's just a glorified assembly language. - Teh Interwebz

    C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, you blow off your whole leg. - Bjarne Stroustrup
    Genie zu sein, bedeutet für mich, alles zu tun, was ich will. - Klaus Kinski

  • Noch was: Ich hab jetzt eine new und free Funktion geschrieben, die dynamsichen nicht lokalen Speicher im Prozessheap alloziiert.
    Das war eines der wichtigsten fehlenden Sachen. Jetzt kann man auch mit richtigen Strings loslegen. Aufgrund dessen hab ich auch nochmal die GetStringvarianten geändert, damit da nicht ein unnötiger String Platz in der exe verbraucht wird:

    ganze funcLib


    Was stört ist, dass word 4 Byte sind. Wenn man etwas auf 2 Byte limitieren möchte oder in einem Array 2 Byte (=Word) breite Elemente hat, muss man das mit ASM machen oder dauernd mittels bitwise AND die vorderen 2 byte wegstreichen.. wofür gibts word, wenn es das gleiche wie int ist..


    PS: Ich denke ich werde auch noch ne ordentliche string-Klasse machen, wenns geht.

    3 Mal editiert, zuletzt von TheShadowAE (29. Oktober 2013 um 16:58)

  • ganze funcLib

    Ich empfehle, die Funktionen für StringCopy, StringCompare, etc nicht selber zu schreiben, sondern das kompilierte Programm gegen eine crt0-Implementierung zu linken. crt0 ist die Standardlibrary von C und enthält u.A. hochoptimierte Versionen für strcpy und außerdem malloc, das manchmal etwas effektiver ist, als HeadAlloc, etc.

  • strcpy etc sind in der Lib (genauso wie in der Funclib) sehr anfällig für Buffer Overflow etc. Ich schreib deswegen alles gerade neu. Ebenfalls hochoptimiert natürlich ^^ Das Linken ist in der Sprache einfach nicht vorgesehen und das ist finde ich das beste an der Sprache. Ich sehe alles im ASM-code. Die gesamte Exe wird assembliert und fertig ist es.
    Das gibt auch kleiner Enddateien

    PS:
    Sowas wie StringInStr ist in der Lib glaub ich auch nicht oder?

    EDIT:
    Es gibt tatsächlich doch strstr^^

  • Hi,

    Zitat

    crt0 ist die Standardlibrary von C und enthält u.A. hochoptimierte Versionen für strcpy

    :rofl::rofl::rofl:
    ehrlich gesagt, dachte ich auch einmal so.... :huh:

    Aber schau mal hier(es geht um die Prozessorbefehle movsb und stosb), wenn du diesen Artikel nicht lesen kannst, renn mal schnell ins nächste Schreibwarengeschäft und lese dir die 2 Seiten in der c´t zu diesem Thema durch....Nur dieser Artikel ist den Preis für das Heft wert!
    Da ist ein Sch*** optimiert, gerade im Gegenteil, die Compiler tun alles dafür, eine KORREKTE Antwort auf den Aufruf von memcpy() und strcpy() zu gewährleisten!
    Die bisher gefertigten Prozessoren sind nämlich alles andere als fehlerfrei und somit müssen die Compiler "hunderte von Fallunterscheidungen" einbauen, um je nach Prozessor die Bugs zu fixen.
    Was dazu führt, dass in den meisten Fällen die Antworten auf die o.g. Befehle zwar immer öfter korrekt ausgeführt werden, aber leider mit dem Handicap von massiv aufgeblähtem Code und langsamer Verarbeitung ;(

  • Ach, James hatte ja noch die Referenz kurz ins Deutsche übersetzt. Sobald ich da die Neuerungen (von 1.5 auf 2.5) vermerkt hab, ergänze ich das noch.

  • So, zum Beginn nächsten Jahre steht die neue Version an. Nachdem nun meine PCs wieder halbwegs einsatzbereit sind und ich endlich auch wieder den Schlüssel zu meinem Billig-Cluster gefunden habe kann das fröhliche Skripten wieder beginnen.

    Was Perseus betrifft: Natürlich ist eine neue Version geplant. Ich bin froh, dass es bis jetzt einen guten Zuspruch und vor allem so tatkräftige Hilfe gab (z.B. durch Shadow). Ich räume zur Zeit den großen Batzen Source-Code auf, damit Perseus in Zukunft ein Gemeinschaftsprojekt werden kann - dafür such ich natürlich Mitwirkende. Wichtige Dinge wie FPU und einige andere fehlen noch, ob nun bei kleinen Schönheitsfehlern oder bei noch viel zu großen Workarounds muss Hand angelegt werden.

    Wenn du also ein wenig Ahnung von Perseus (und/oder (F)ASM) hast und vor momentan noch etwa 11 Leveln an Nesting keine Angst hast, würde ich mich sehr freuen, dich im Team begrüßen zu dürfen. Ob nun "nur" das Verfassen und Strukturieren von Includes oder die Arbeit am Kernel (das ist und bleibt verwirrend und kompliziert ;) , es macht imho Spaß und das Ergebnis wird immer praktischer! Bitte bei Interesse PN an mich :)

    minx

  • Hi,
    bitte, wie schon einmal angesprochen, die benötigten Files "unkomprimiert" (wegen mir in einer "Special-Edition" ) zur Verfügung stellen.
    1. ist es suboptimal, Virenscanner "umzubiegen" damit fremde Exe´n keine "Fehlalarme" :rolleyes: verursachen ("Alda, da is kein Virus oder Backdoor drin, ISCH SCHWÖR")
    2. ist die FASM.dll von Haus aus nicht gepackt
    Installer wäre nett, da gibt es eine Scriptsprache für....moment mal, gleich hab ichs...AutoIt :thumbup:

  • Moin.

    Der aktuelle Kurs sieht so aus: Der Compiler enthält jetzt eine Standardbibliothek, die sog. coreLib. Sie enthält Funktionen wie print / printi / printui / string / time usw. um die Erstellung vor allem von Konsolenanwendungen zu erleichtern und die Nutzung und Notwendigkeit von Includes zu minimieren.

    Desweiteren wird main und end durch { } ersetzt. Nun kann man zum Beispiel das Hello, World-Programm in eine Zeile fassen, ganz ohne Includes oder Prototypen:

    Code
    {print("Hello, World!~r~n");}

    Natürlich gibt es für die Byte-Sparer eine Option, ob der Compiler die coreLib in das Programm linken soll oder nicht.

    So weit erstmal dazu :)

    // Ach ja, alles ist wie immer trotzdem nochmal schneller geworden ^^

    Einmal editiert, zuletzt von minx (6. Dezember 2013 um 21:12)

  • Sehr schön, das Update ^^
    Ich weiß zwar nicht mehr, was es alles für kleine Bugs gab, aber soweit ich das bis jetzt beurteilen kann gibt es die nicht mehr alle ^^

    Alles was ich bis jetzt zu meckern gefunden hab:
    - Es ist keine Addition auf Pointer möglich!
    - renew, free, stringui fehlen in der coreLib (oder wie heißen die?).
    - Ich hätte die coreLib lieber im Ordner (sichtbar), damit ich gucken kann, welcher Funktionen es gibt, wie sie funktionieren und damit man etwas hinzufügen kann o.ä. wie man will. Die /c0 Option ist allerdings schonmal gut, so kann ich die immerhin die alte funcLib von mir benutzen um "free" etc. zu haben.
    - ein Include-Hauptverzeichnis wär super. Dann muss man nicht immer den ganzen (relativen) Pfad zur funcLib etc. angeben.

  • Hi,
    ich weiss nicht, ob mein "Problem" überhaupt hier hin gehört.
    Beim Testen des OpenGl-Beispiels ist mir aufgefallen, dass alle 6 Cores meiner CPU auf Höchstleistung laufen?!
    Daraufhin habe ich andere AutoIt-OpenGl-Beispiele ausprobiert und dort dieses Phänomen auch festgestellt.
    Ist das bei euch auch so und an was liegt das?
    System Win7-64
    FX-6300
    Radeon 7790
    Catalyst-Treiber 13.12
    OpenGL-Version 6.14.10.12618

  • Das ist mir bei AutoIt noch nie passiert. Es wird immer nur ein Kern ausgelastet (das Skript läuft ja auch nur auf einem Thread -> einem Kern).

  • Der Support / die Refrenz für Perseus 2.6 ist eingestellt. Den Download lasse ich noch so lange wie möglich verfügbar, bevor bald Perseus++ herausgegeben wird.

    Einmal editiert, zuletzt von minx (29. Januar 2014 um 22:45)

  • Wie bekannt sein sollte, wird aktiv an Perseus 4 gearbeitet (das übrigens einige Philosophien mit Apples kürzlich angekündigten "Swift" teilt). Ich muss leider mitteilen, dass mit der Markteinführung von Windows 8.1 und dessen Erfolg nun auch der letzte meiner PCs mit Windows 8 versehen wurde. Es bringt nichts, eine neue Sprache auf alte Runtimes zu stützen. Besagte Runtimes sind schon in Win 8 nicht mehr kompatibel und nun in Win 8.1 nicht mehr vorhanden.

    Deswegen muss die Entwicklung der neuen Perseus Version anders als geplant erfolgen. Dazu soll der Compiler portiert werden. In der Diskussion sind C oder AutoIt (andere Sprachen werden nicht einbezogen). Die Perseus-eigene DirectByte Runtime ist glücklicherweise immernoch einsetzbar und Microsofts Worten zu folge wird sie das bis zum Support-Ende von Win8.1(!) garantiert bleiben. Die Portierung eines kompletten Compilers ist mehr als nur wenig Aufwand. Ich bin froh, dass zwischen Quellsprachen und Zielsprachen kein Paradigmenwechsel stattfindet ;) .

    Dieser Aufwand beansprucht Zeit. Viel Zeit. Deswegen: Mit Perseus 4 ist nicht in nächster Zeit zu rechnen. Wenn es aber ein offizielles Release gibt, dann wird auch der Source-Code mit veröffentlicht (deswegen tendiere ich auch eher zu AutoIt).

    Naja, so long!

    (Für alle Perseus++ und Perseus 3.X Besitzer: Diese Versionen werden höchstwahrscheinlich nicht zu 4 kompatibel sein.)