Fur grosse Fakultaeten verwendet man Stirling.
Damit kriegst du aber nur Näherungen raus. Für nahezu alle praktischen Anwendungen dürfte das natürlich reichen; aber hier ging es ja um den exakten Wert.
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 enthusi am
Fur grosse Fakultaeten verwendet man Stirling.
Damit kriegst du aber nur Näherungen raus. Für nahezu alle praktischen Anwendungen dürfte das natürlich reichen; aber hier ging es ja um den exakten Wert.
Und BCD ist doch im kaufmaennischen Bereich zu Hause? Sauberere Rundung etc.
Was bei Integern/Festkomma aber keine Rolle spielt, sondern nur bei Floats.
Daher totale Verschwendung bei 6502, weil man die BCD-Funktionalität ohne Probleme in Software abbilden kann.
Aber es wurde dennoch als Verkaufsargument eingebaut, vielleicht, weil das wohl auf diversen Ausschreibungs-Checklisten eben auftauchte.
Und BCD ist doch im kaufmaennischen Bereich zu Hause? Sauberere Rundung etc.
Früher schon. Was ich da heute im SQLServer und so finde, money und decimal, sind Binärzahlen mit festem Komma.
Aber es wurde dennoch als Verkaufsargument eingebaut, vielleicht, weil das wohl auf diversen Ausschreibungs-Checklisten eben auftauchte.
Ich kenne es aus Cobol und dem EBCDIC-Code der alten Großrechner. Amerikanische Rechner haben glaub ich recht lange nicht richtig binär, sondern im 10er-System gerechnet, und das hat sich dann über Cobol, EBCDIC und IBM lange gehalten (meine Vorstellung davon). Aus der Perspektive der 70er finde ich das sehr vernünftig.
Und auch der 8086 konnte mit BCD-Zahlen umgehen, allerdings nicht so elegant wie der 6502. Er brauchte einen extra Befehl, AAA.
Edit: Ups, schon so lange her. Der Befehl ist DAA.
Irgendwann wurde im 64'er ein Programm veröffentlicht, mit dem man die Fakultät von 10000 berechnen konnte.
Hat dafür der Speicher ausgereicht? Wenn ich mir die Fakultät von 20! = 2.432.902.008.176.640.000 anschaue, dann frage ich mich wieviel Platz die Falkultät von 10.000 benötigt.
Irgendwann wurde im 64'er ein Programm veröffentlicht, mit dem man die Fakultät von 10000 berechnen konnte.
Hat dafür der Speicher ausgereicht? Wenn ich mir die Fakultät von 20! = 2.432.902.008.176.640.000 anschaue, dann frage ich mich wieviel Platz die Falkultät von 10.000 benötigt.
Als Binärzahl benötigt man 14808 Byte. Mit BCD sind es 17830 Byte.
PS: 30000! würde übrigens in beiden Formaten (mit 50k/60k) auch noch ins C64-RAM passen...
diesen Modus hielt ich bisher für reinste Transistorverschwendung. Jetzt nur noch reine.
Naja, für die Umwandlung Binär zu Dezimal ganz praktisch, aber auch für die Umwandlung von Dezimal -> Hex kann man mit dem Decimal-Mode tricksen.
Ich könnte mir noch vorstellen, dass er für das Handling der Echtzeituhren in den CIAs irgendwie von Bedeutung sein könnte. Die benutzen ja auch die BCD-Darstellung. Aber ansonsten ist mir bislang auch keine Idee gekommen, wo man den sonst noch brauchen könnte...
Die BCD-Darstellung an sich nützt den Decimal-Mode ja noch nicht. Aber wenn man dann mit BCD-Werten rechnet ... also z.B. wenn man einen Alarmwert der RTC relativ zu aktuellen Zeit setzen möchte, dann kann man die Zeit zum aktuellen Stand im BCD-Modus dazurechnen und damit den Alarmwert setzen.
Ich hatte da auch noch den Gedanken, dass man erstmal alle Primfaktoren sammeln und neu zusammenstellen könnte. Könnte auf Prozessoren mit Mul-Befehl nützlich sein, aber ich sehe grad nicht, wo das auf dem C64 nützlich wäre.
Noch ein bisschen drüber nachgedacht, und ich habe das Gefühl, dass sich das auch am C64 lohnen könnte. Zumindest beim Multiplizieren mit KB-Großen Binärzahlen.
Aus den Faktoren lassen sich andere zahlen zusammenstellen, die 8/16 Bit besser ausnutzen oder weniger 1Bits enthalten.
3, 7 und 11 haben zusammen 8 gesetzte 1Bits, was entsprechend viele Shifts und Additionen mit der großen Zahl bedeutet.
Multipliziert ergeben sie 231, die Zahl hat nur 6 gesetze Bits, was 2 Additionen spart.
Ist jetzt die Frage, wie man die Original-Faktoren am besten zerlegt und wie man die hübscheren, neuen Faktoren findet.
Ich könnte mir noch vorstellen, dass er für das Handling der Echtzeituhren in den CIAs irgendwie von Bedeutung sein könnte. Die benutzen ja auch die BCD-Darstellung. Aber ansonsten ist mir bislang auch keine Idee gekommen, wo man den sonst noch brauchen könnte...
Die BCD-Darstellung an sich nützt den Decimal-Mode ja noch nicht. Aber wenn man dann mit BCD-Werten rechnet ... also z.B. wenn man einen Alarmwert der RTC relativ zu aktuellen Zeit setzen möchte, dann kann man die Zeit zum aktuellen Stand im BCD-Modus dazurechnen und damit den Alarmwert setzen.
Sowas meinte ich.
Noch ein bisschen drüber nachgedacht, und ich habe das Gefühl, dass sich das auch am C64 lohnen könnte. Zumindest beim Multiplizieren mit KB-Großen Binärzahlen.
Aus den Faktoren lassen sich andere zahlen zusammenstellen, die 8/16 Bit besser ausnutzen oder weniger 1Bits enthalten.
3, 7 und 11 haben zusammen 8 gesetzte 1Bits, was entsprechend viele Shifts und Additionen mit der großen Zahl bedeutet.Multipliziert ergeben sie 231, die Zahl hat nur 6 gesetze Bits, was 2 Additionen spart.
Ist jetzt die Frage, wie man die Original-Faktoren am besten zerlegt und wie man die hübscheren, neuen Faktoren findet.
Ist sicherlich eine Möglichkeit. Bei meinem Programm dürfte das kaum einen Vorteil bringen, da es nur addiert, wenn ich mich recht erinnere - ich hab' mir den Sourcecode bislang nicht angeschaut. (An was ich mich zu erinnern glaube: Für jede zu multiplizierende Zahl wird eine Multiplikationstabelle durch sukzessive Addition erstellt, und dann einfach für jede Ziffer der entsprechende Wert nachgeschlagen und zum bisherigen Ergebnis addiert (mit entsprechendem Versatz natürlich).)
Ist sicherlich eine Möglichkeit. Bei meinem Programm dürfte das kaum einen Vorteil bringen, da es nur addiert, wenn ich mich recht erinnere - ich hab' mir den Sourcecode bislang nicht angeschaut. (An was ich mich zu erinnern glaube: Für jede zu multiplizierende Zahl wird eine Multiplikationstabelle durch sukzessive Addition erstellt, und dann einfach für jede Ziffer der entsprechende Wert nachgeschlagen und zum bisherigen Ergebnis addiert (mit entsprechendem Versatz natürlich).)
Reingeguckt und in eine Textdatei "ausgedruckt" hab ich ihn. Aber ich bin leider auch nicht mehr so fit darin, durch fremden oder alten Code durchzusteigen (bzw. ist meine Geduld schon nach 60 Sekunden aufgebraucht)
diesen Modus hielt ich bisher für reinste Transistorverschwendung. Jetzt nur noch reine.
Naja, für die Umwandlung Binär zu Dezimal ganz praktisch, aber auch für die Umwandlung von Dezimal -> Hex kann man mit dem Decimal-Mode tricksen.
Praktisch: ja, notwendig: nein. So häufig wandelt man die ja nicht um.
Praktischer wären stattdessen weniger fehlende Opcodes gewesen, z.B. bei der direkten oder indirekten Zeropage-Adressierung.
Ja, eintauschen wuerde ich den dezimal mode sofort
Nervt ja auch sowie man IRQs verwendet enorm.
Was der BCD Modus in der Praxis am C64 für einen Nutzen bringen kann, wird im folgend verlinkten Video vom YT-Kanal 8-Bit Show And Tell anschaulich erläutert (Punktestand umrechnen und anzeigen mit Kernel Routine $BDCD vs. Binary Coded Decimal):
Was der BCD Modus in der Praxis am C64 für einen Nutzen bringen kann
Der Punkt ist ja, dass das eher sinnloser (im Vergleich zu mehr Opcodes) syntaktischer Zucker ist.
Kann man alles auch anders erledigen.
Der Punkt ist ja, dass das eher sinnloser (im Vergleich zu mehr Opcodes) syntaktischer Zucker ist.
Kann man alles auch anders erledigen.
Der Punkt ist vermutlich eher, dass so etwas einst ein notwendiges Feature war, weil es die Konkurenz auch hatte oder als Marketing-Argument notwendig war (da hätte die Konkurrenz gleich mit dem Finger auf den 65xx gezeigt - "billig, aber kann nicht mal mit BCD rechnen"). Ob das dann als Decimal Mode oder als Decimal Adjust relisiert ist, spielte da eher keine Rolle.
Und ich glaube, die Logik in der Realisierung ist ziemlich gering im Vergleich zu einem neuen Befehl (wenn man von Trivialbefehle wie SED oder CLD absieht) oder einem Adressierungsmodus.
Wie schon erwähnt, ich halte das nicht für ein Marketing-Gimmick.
BCD war bei den großen Mitte der 70er noch kein Exot, sondern ganz normal.
So, wie mal PCs mit Diskettenlaufwerk normal und das Weglassen revolutionär waren.
Der Punkt ist ja, dass das eher sinnloser (im Vergleich zu mehr Opcodes) syntaktischer Zucker ist.
Kann man alles auch anders erledigen.
Der Punkt ist vermutlich eher, dass so etwas einst ein notwendiges Feature war, weil es die Konkurenz auch hatte oder als Marketing-Argument notwendig war (da hätte die Konkurrenz gleich mit dem Finger auf den 65xx gezeigt - "billig, aber kann nicht mal mit BCD rechnen"). Ob das dann als Decimal Mode oder als Decimal Adjust relisiert ist, spielte da eher keine Rolle.
Ach so!
Aber es wurde dennoch als Verkaufsargument eingebaut, vielleicht, weil das wohl auf diversen Ausschreibungs-Checklisten eben auftauchte.
Und ich glaube, die Logik in der Realisierung ist ziemlich gering im Vergleich zu einem neuen Befehl (wenn man von Trivialbefehle wie SED oder CLD absieht) oder einem Adressierungsmodus.
Ähnlich gering, wie die vorhandene Logik zu etwas wie "STA zp,Y" oder "CPY zp,X" oder "TXY" zu verdrahten. Um neue Befehle oder Adressierungsarten ging es ja gar nicht.