ZitatDas 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.
darum nimmt man ja standard ieee floats
Du bist in Begriff, Forum64 zu verlassen, um auf die folgende Adresse weitergeleitet zu werden:
Bitte beachte, dass wir für den Inhalt der Zielseite nicht verantwortlich sind und unsere Datenschutzbestimmungen dort keine Anwendung finden.
letzter Beitrag von ThomBraxton am
ZitatDas 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.
darum nimmt man ja standard ieee floats
Hallo!
Was heisst 'für das Zielsystem'? Er benutzt z.B. das IEEE Format. Da er ja alles selbst mit den Zahlen macht inkl. Ein/Ausgabe kann sich der Compiler-Autor das Format ja aussuchen. Und da der cc65 ja weiterhin diverse Plattformen (wie Atari z.B.) unterstützen soll, fällt die Benutzung der c64-Rom-Routinen quasi eh flach. Es sei denn man macht das über irgendwelche ifdefs, so dass der Compiler je nach Plattform unterschiedliche Formate nutzt. Wobei das wieder Probleme in den Math-Routinen gibt, die ja von einer bestimmten Genauigkeit ausgehen.
Eigentlich braucht man ja nur eine ganz begrenzte Anzahl von Operationen:
cast int -> float (hier könnte man auch gleich long nehmen, und short bzw. int immer auf long casten).
Die 4 Grundrechenarten +,-,*,/ wobei man ggf. noch die Invertierung separat schreiben könnte.
Alles andere kann man doch erstmal in C machen und es ggf. später mit etwas Assembler tunen. Wobei ich im Hinterkopf immer noch einen Artikel über die trigonometrischen Funktionen im c64 Rom hab, und das die nicht wirklich optimal waren. Weiss aber nicht mehr, wo ich das mal aufgeschnappt hab...
Was vergessen: @sauhund: neg kehrt das Vorzeichen um und rnd tut runden, richtig?
Ciao,
Andreas
Edit: sauhund, Du bist zu schnell für mich...
rnd ist natürlich random
Aaaargh....das hab ich überall als rand() gefunden....dann ist klar, warum nix geht...
Hallo, Andreas!
Hier war zumindest ein Fehler:
Hatte schon eine Zusammenfassung versucht http://wiki.cc65.org/doku.php?id=cc65:roadmap
übrigens gibt es in Version 2.13.9 cc65_sin() und cc65_cos().
Gruß,
Stefan
Dicken Dank für den Fehler-Hinweis! Nun hat er schonmal ein Pixel gemalt....allerdings bisher nur _genau_ eines...und noch kein Zweites...
Braucht also noch etwas Liebe...
Diese Zusammenfassung hatte ich gesehen...aber sie hat ja Diskussion 2004 zusammengefasst. 2010 gab es ja nochmal einen länglichen Thread, der irgendwie zu keinem Ergebnis geführt hat.
Wo sind diese cc65_sin() und cos Funktionen? Ich hab hier die aktuellen svn Sources und da find ich erstmal nix...
Ciao,
Andreas
PS: Stimmt es, dass fneg den float Wert negiert? Also aus den 144 dann -144 macht?
sollte, ja. es kann aber auch durchaus sein das da noch fehler in dem code sind - ernsthaft getestet hab ich das nie
Ich wollte mir in der Schleife mal per TGI die aktuellen Koordinaten ausgeben lassen. Geht auch nicht. Als ob die Schleifen gar nicht laufen. Vermutlich ist es am Besten, wenn man die Grafik mal komplett abschaltet, und erstmal im Testmodus debugged.
Hier die Version, die nicht tut:
Ciao,
Andreas
PS: jetzt mal ohne Grafik probiert...
_ftoi scheint schonmal nicht richtig zu funktionieren. Der Ausdruck
xfMax = _ftoi( _fadd( _strtof( "0.5"), ( fsqr( _fsub( _fmul( yfMin, yfMin), _fmul( yf, yf))))));
ergibt 0, obwohl der Ausdruck _fadd .... 5 ergibt. Was wiederum auch falsch sein müsste, weil yfMin am Anfang doch gleich yf ist, also der Ausdruck in der Wurzel 0 wäre.
Vielleicht wäre es sinnvoll, mal eine Testsuite für die Funktionen zu schreiben, damit man mal sieht, welche Funktion welche Ergebnisse bringt?
ZitatVielleicht wäre es sinnvoll, mal eine Testsuite für die Funktionen zu schreiben, damit man mal sieht, welche Funktion welche Ergebnisse bringt?
klar, ich hatte mir das bisher gespart weil der aufwand eine auch nur halbwechs umfassende testsuite zu schreiben doch nicht zu unterschätzen ist - und ich das daher lieber dann machen würde wenn der compiler die datentypen schon kennt (sonst darf man nacher alles wieder umschreiben). und wenn letzteres so ist könnte man sich evtl das schreiben einer testsuite komplett sparen, weil es da schon fertige gibt ("paranoia"), welche nicht nur allumfassend sind sondern auch obskure grenzfälle abklopfen auf die man selber garnicht kommt wenn man sich nicht wirklich sehr genau mit floats auskennt.
also: uz bearbeiten das das mal da rein kommt, langsam wirds doch mal zeit
Wenn man wirklich die 32-Bit Typen nimmt, dann könnte man ja erstmal die float-Ops als Long implementieren und dann schrittweise die korrekten Ops einbauen. Damit würde zumindest mal das Pushen und Poppen der Variablen auf den Stack funktionieren. Auch Zuweisungen müssten identisch funktionieren.
Ich les gleich mal ein bischen in den cc65 Sources...
Ciao,
Andreas
mmmh du meinst, einfach die runtime funktionen für longs durch welche für floats ersetzen? könnte fast funktionieren.... wenn der codegenerator nicht intern dinge mit longs tut die dazwischen funken *theoretisch* sollte das ja dann fast durch umbenennen (und evtl ein bischen anpassen) der routinen die ich da hab zu machen sein....
Nicht ersetzen. Ergänzen. Wenn der Compiler eine float-Var sieht, soll er sie einfach mal als long behandeln.
Wobei die floats ja schon an fast allen Stellen drin stehen. Wenn wir z.B. erstmal den Error in codegen.c Zeile 74 rausnehmen.
Dann das Laden und Speichern implementieren. Ab Zeile 645 könnten wir die floats wie longs behandeln. Sind ja ebenfalls 4 Byte.
Hallo!
stefan: Ich habe erstmal noch einen Fehler in den Schleifen gefunden. Aber in allen Fällen werden die Schleifen nur _einmal_ durchlaufen, was eigentlich nicht sein darf.
Problem: folgender Vergleich am Schluss liefert 0, obwohl ja -144 kleiner ist als 144. Das Ergebnis müsste also doch -1 sein, oder?
Ciao,
Andreas
ZitatProblem: folgender Vergleich am Schluss liefert 0, obwohl ja -144 kleiner ist als 144. Das Ergebnis müsste also doch -1 sein, oder?
nö, wieso? das ist C und nicht basic wahr gibt 1 und falsch gibt 0
nö, wieso? das ist C und nicht basic wahr gibt 1 und falsch gibt 0
Hmm, warum steht in deinem Kommentar a=0 (== ) / a=1 (>) / a=255 (<)?
Mein Vorschlag "unsigned char _fcmp()" sollte signed sein.
Ja, 19:40 ist eine heftige Uhrzeit ...
uw, sorry. ja. ich nehme alles zurück und behaupte das gegenteil um die uhrzeit brauch ich erstmal kaffee,... =P
stefan: also im Original C gibt ja anscheinend diese fcmp Funktion nicht, weil es dort ja die Operatoren <, == und > gibt. Also hab ich mich mal an die strcmp Funktion gehalten:
http://home.htw-berlin.de/~jun…ref/FUNCTIONS/strcmp.html
Danach müsste sie nur <0, 0 oder eine Zahl > 0 zurückgeben, um das Verhältnis der beiden Argumente zu bestimmen. Ich hatte das irgendwie so im Kopf, dass sie -1, 0 oder 1 zurückgibt. Allerdings hab ich mich zum letzten Mal unter Zorland C so richtig mit den Funktionen beschäftigt. Was also eeeewig her ist.
Wenn Du die Funktion wirklich nur als Gleichheits-Test nutzen willst, bräuchte man noch eine Methode, um auch kleiner und grösser testen zu können...
Sollen wir jetzt mal versuchen, den cc65 zu patchen? Einen Einstiegspunkt hätten wir ja schonmal.... Oder erst Uz anhauen?
Ciao,
Andreas
polluks: Danke für den Patch! Muss jetzt leider weg, aber schau es mir später oder Morgen mal an.
Was ich schon ne Weile überlege: muss das wirklich Assembler sein? Sogar im cc65 müsste es doch möglich sein, sogar die grundlegenden Operationen in C zu schreiben, indem man natürlich nur int-Typen verwenden könnte. Wenn man diese Funktionen so schreibt, dass sie ohne Argumente aufgerufen werden, sondern einfach nur die Akkus (die an festen Adressen sind) benutzen, müsste der Compiler ja nur die Argumente in die Akkus bringen und dann ein jsr <operation> machen, oder?
Ciao,
Andreas