Real-Zahlen und Funktionen im cc65 nutzen...zur Umsetzung

Es gibt 76 Antworten in diesem Thema, welches 15.232 mal aufgerufen wurde. Der letzte Beitrag (29. Juli 2014 um 17:23) ist von ThomBraxton.

  • Ich habe alle Realfunktionen aus dem Buch "C64 Proggen in Maschinensprache" von Kassera für mich umgesetzt.

    Vielleicht möchte der eine oder der andere die mal so umsetzen für den cc65 das sie evtl als "lib" genutzt werden können.
    Ich kann es nicht.
    Aber es gibt hier ja einige C-Spezialisten, die das aus dem Handgelenk machen können.

    danke.

  • Zitat

    Aber es gibt hier ja einige C-Spezialisten, die das aus dem Handgelenk machen können.


    die würden das dann aber in C machen, und dann weinst du wieder rum weil dir das zu kompliziert ist =)

  • Hmmm.., ich hab hier den C64 um ihn auch so zu nutzen wie er geschaffen wurde mit dem ROM/RAM, das ist mein Hobby. Ich selber möchte den nicht so aufmotzen als Rennwagen, so das man nichts C64-Typisches wieder findet.

    Ich finde es Toll , so das innenleben so zu nutzen, das ist Nostalgie..., mir ging es nur darum, die Struktur mal besser umzusetzen, nicht die Realroutinen neu schreiben, das bringt keine freude mehr um damit zu spielen.
    Dann sollte man lieber gleich beim PC bleiben, wenn man den C64 immer schneller haben will um Pc-Ähnliche Strukturen zu bewundern an der Maschine. Also nicht so hoch hinaus damit.


    Schade...

    danke.

    gruss

  • LOL

    [ ] du hast genau verstanden was ich sagte

    Zitat

    mir ging es nur darum, die Struktur mal besser umzusetzen


    vielleicht ging es dir darum - rausgekommen ist aber was ganz anderes =)

  • Hmmm.., ich hab hier den C64 um ihn auch so zu nutzen wie er geschaffen wurde mit dem ROM/RAM, das ist mein Hobby

    Dann darfst du aber nicht hingehen und einen C-Compiler mit ASM und BASIC vergewaltigen.
    Dann MUSST du nur in BASIC programmieren, egal wie schnell das ist.

  • Dann darfst du aber nicht hingehen und einen C-Compiler mit ASM und BASIC vergewaltigen.

    Es ist nur eine Nutzung des eingebauten Inventar. :zustimm:

    Aber wie schon mal angedeutet , viele haben hier Spannungen damit und keine Freude mal Experiemente zu machen.
    Muss aber schlimm sein für einen..der so etwas verkrampft sieht an einer Daddelmaschine. :(

    danke.


    gruss

  • Hallo!

    Es geht doch ein wenig darum, einen gewissen Minimal-Standard an Portabilität zu haben, wenn man schon C nutzt. Dort wurde ja mit math.h ein ganz ordentlicher Standard gesetzt, den man möglichst weit umsetzen sollte. Denn wenn man mal einen Algorithmus oder ein Progrämmchen auf dem 64er ans Laufen bringen möchte, dann will man ja nicht gleich jede Zeile neu schreiben müssen.

    Hier steht eine ganz nette Beschreibung:

    Bitte melde dich an, um diesen Link zu sehen.

    Ich finde es toll, dass Du Dir die Mühe gemacht hast, aber Du solltest vielleicht noch einen Schritt weiter gehen, und ein besseres Interface zu den eigentlichen C-Funktionen basteln. Damit halt so etwas möglich wird, wie float x = sin( 0.5); , oder so.

    Evlt. wäre es ja auch sinnvoller, die ganze Sache erstmal nur in C zu machen und dann ggf. zu schauen, wie man die Funktionen schrittweise beschleunigen kann. Von einigen Libs sind ja die Sources verfügbar (Minix z.B., aber dort geht fast alles über double) , die man evtl. auf den 64er portieren könnte? Vielleicht so als kleines Forums-Projekt?

    Hier ist z.B. was:

    Bitte melde dich an, um diesen Link zu sehen.

    Ein Wurzel-Funktion für floats. Furchtbar formatiert, wie ich finde, und auch mit einigen Stolperstellen, aber man könnte sowas evtl. ans Laufen bekommen, wenn ich nicht ganz falsch liege...

    Ciao,
    Andreas

  • Zitat

    Du solltest vielleicht noch einen Schritt weiter gehen, und ein besseres Interface zu den eigentlichen C-Funktionen basteln.


    sowas hatte ich ja Bitte melde dich an, um diesen Link zu sehen. mal gemacht, das war ihm aber zu kompliziert =P

    Zitat

    Damit halt so etwas möglich wird, wie float x = sin( 0.5);


    das würde dann allerdings auch eingriffe in den compiler selbst nötig machen, der kennt den datentyp float ja noch nicht :) (edit: es geht aber "fast" - man muss halt alle konstanten händisch ins float format umrechnen, da der compiler die ja nicht kennt)


  • sowas hatte ich ja Bitte melde dich an, um diesen Link zu sehen. mal gemacht, das war ihm aber zu kompliziert =P


    das würde dann allerdings auch eingriffe in den compiler selbst nötig machen, der kennt den datentyp float ja noch nicht :) (edit: es geht aber "fast" - man muss halt alle konstanten händisch ins float format umrechnen, da der compiler die ja nicht kennt)

    So ganz unbekannt sind dem Compiler ja diese Datentypen nicht. Sie stehen ja schon im Scanner und sogar im Codegenerator drin. Aber die Diskussion auf der Mailing-Liste dreht sich ja so ein bischen im Kreis. Der cc65 Autor lehnt die 64-bit doubles ab, weil er sie zu langsam findet, und der C-Standard fordert mehr als 32-Bit floats. Ich persönlich hätte lieber langsame 64-Bit doubles als gar keine. In einem Action-Spiel wird man die eh nicht nutzen können. Aber um mal eine Sinus-Kurve zu rechnen sollte es schon reichen.

    Ciao,
    Andreas

  • Zitat

    Sie stehen ja schon im Scanner und sogar im Codegenerator drin.


    oh tatsächlich? das war damals nicht so :) vielleicht guck ich da doch mal rein .... (mir würden 32bit doubles völlig reichen, auch 32bit floats braucht man nicht wirklich =P)

  • Hier geht ein langer Thread zum Thema los:

    Bitte melde dich an, um diesen Link zu sehen.

    Vielleicht sollte man sich mal auf der Liste anmelden, um die Diskussion wieder anzuschieben...

    Ciao,
    Andreas

    PS: das ich die Sources mal gelesen hab, lag daran, dass ich bei Sources mit float drin, eine Fehlermeldung bekam, dass dieser Datentyp derzeit nicht unterstützt würde. Also kein Syntax-Error, oder so...

  • die diversen diskussionen auf der liste kenne ich natürlich, ich hab da ja auch mal den source gepostet :)

  • @sauhund: es wäre toll, wenn es in Deiner Lib noch ein paar weitere Funktionen gäbe. Z.B. sin und cos. Wollte gerade mal die Performance von floats testen und per tgi eine einfache Sinus-Kurve malen. Geht schlecht ohne Sinus-Funktion. Dann sollten vielleicht ein paar wichtige Konstanten, wie Pi per Default definiert sein, damit man sie gleich verwenden kann?

    Vielleicht könnte man z.B. mal die Sinus-Sources, die ich oben gepostet hab, mal in Deiner Lib implementieren? Was meinst Du?

    Ciao,
    Andreas

  • Zitat

    es wäre toll, wenn es in Deiner Lib noch ein paar weitere Funktionen gäbe. Z.B. sin und cos. Wollte gerade mal die Performance von floats testen und per tgi eine einfache Sinus-Kurve malen. Geht schlecht ohne Sinus-Funktion. Dann sollten vielleicht ein paar wichtige Konstanten, wie Pi per Default definiert sein, damit man sie gleich verwenden kann?


    ääääh. guck mal in math.h - es gibt alle wichtigen funktionen (halt alle die es im rom gibt) und PI ist auch vordefiniert =)

    Zitat

    Vielleicht könnte man z.B. mal die Sinus-Sources, die ich oben gepostet hab, mal in Deiner Lib implementieren? Was meinst Du?


    das wäre nur als fingerübung interessant - der code der da rauskommt wäre mit ziemlicher sicherheit unbenutzbar langsam :=P

  • Entschuldige bitte das Übersehen von math.h ... ich bin anscheinend blind... :)

    Ok, eine Sinuskurve wird mal gemalt. Ist erstmal nur ein übler Hack, um mal eine Idee von Geschwindigkeit der Float's zu bekommen. Ich find sie bisher mehr als annehmbar (für einen Retro-Compi halt). Wenn Doubles halb so schnell wären (also der cc65 Autor sie als 8-Byte Typen implementieren würde), hätte ich damit noch kein Problem.

    Zusammengehackte Sources der Sinus-Kurve (ist nur eine abgeänderte TGI-Demo):

    Ich attach mal ein D64-Image, damit man sich ggf. einen Eindruck vom Tempo machen kann. Einfach ftest starten. Dann fehlt da ein Stückchen der Kurve. Evtl. ist man da überm Rand, oder die Funktionen klemmen da an einer Stelle. Muss ich mal schauen...

    Ich bin am Grübeln, das mal in 3d zu probieren. Also z = sin(x) * cos(y) , oder so. In isometrischer Darstellung. Da gab es mal paar Basic-Listings in der Runtime, oder so. Mal schauen, ob ich mich motivieren kann... :)

    Ciao,
    Andreas

  • Ich hab also mal was zusammen gehacked nach einer Formel, die ich in Data Becker's Tipps und Tricks gefunden hab. Alles noch komplett ohne Optimierung. Läuft anscheinend noch nicht richtig (im Moment malt er noch nix, aber vielleicht ist es auch einfach zu langsam), aber man bekommt schon einen Eindruck, wie die fp Sources so aussehen. Sie sind eher schwierig zu debuggen, wie ich finde. Vielleicht muss man sich auch einfach erst an die Schreibweise gewöhnen, aber die normale C-Schreibweise find ich besser eigentlich besser zu lesen...

    Ciao,
    Andreas

  • Ich würde mir da wahrscheinlich was in Python zusammen hacken was einen Ausdruck in diese Funktionsaufrufform bringt. Das ist ja echt gruselig zu lesen.

  • Ich hab auch schon drüber gegrübelt, ob man z.B. eine freie Grammatik, wie die von Antlr z.B. nimmt, um daraus einen Parser zu basteln, der die float-Ops ersetzt. Das Problem ist, dass man ja float-Ops von int-Ops unterscheiden muss, was die meisten Grammatiken nicht so wirklich machen. Da gibt es halt solche Regeln wie expr + expr und irgendwann wird dann unterschieden, dass expr sowohl float, also auch int sein kann.

    Vielleicht sollte man es (wenn es läuft) auf der cc65-Mailing Liste posten und Uz baut doch noch floats ein?

    Ich studier nochmal die cc65 Sources. Vielleicht find ich ja auch nen leichten Einstieg, wie man die float Ops einbauen könnte...

    Ciao,
    Andreas

  • Ein Problem dürfte sein, das der Compiler Floats für das Zielformat erstellen können muss. Es sei denn Du lässt ihn da Zeichenketten schreiben, die erst zur Laufzeit umgewandelt werden. Und wenn er optimieren können soll, muss er mit der gleichen (Un)Genauigkeit rechnen wie die Routinen auf dem Zielsystem. Das heisst wenn man Unterstützung für Gleitpunktzahlen implementieren möchte, muss man das sowohl für den 6510 als auch in C für den Compiler machen.