|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Programmierung > value to dezimal string | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
| 1 -2- | [ - Beitrag schreiben - ] |
|
25.07.2009, 15:45 Uhr jolo Posts: 110 Nutzer |
@HolgerZitat: Da muss ich Dir doch glatt Recht geben. Zu meiner Entschuldigung muss ich aber anführen, dass ich davon ausgegangen bin, dass man versteht was auch schon innerhalb der ursprünglichen Routine geschieht: Nämlich (damals) langsame Divisionen durch schnellere Subtraktionen zu ersetzen. Zitat: Du kannst mich halten für was Du willst. Was ich nicht mag, und das betrifft nicht nur programmieren, ist Kritik zu äußern ohne Lösungen aufzuzeigen. Auch etwas als schlecht programmiert zu bezeichnen, wenn man die Vorgehensweise des betreffenden Codes noch nicht richtig verstanden hat, und damit dann anderen ein falsches Bild dessen vermittelt, was als Lösung herangezogen werden kann, halte ich auch nicht für sonderlich hilfreich. Ich habe zum Nachvollziehen des Quellcode nicht einmal eine Minute gebraucht obwohl ich mein letztes größeres Assembler-Projekt in 1995 geschrieben habe. Aufgefallen ist mir nämlich der Wert 10000; da hätte es auch bei Dir klingeln können. 10000 wurde früher immer zum Subtrahieren von Wort-Werten benutzt und danach durch 10 geteilt, spricht 1000. 1000 durch 10 = 100 - und so fort. Demnach habe ich nur nach Übereinstimmungen gesucht, et voila, ich wusste wie der Code funktioniert. Ich erwarte von keinem Leser dieses Forums dass er es auch erkennt, aber ich denke dass Kritik nur der äußern darf, der auch Lösungen parat hat. Einfach nur etwas schlecht zu reden geht meiner Meinung nach nicht in Ordnung. Und nur deshalb habe ich mich überhaupt eingeschaltet. Zitat: Aber nicht mehr lange. Werde das Gefühl nicht los, dass ich Grünen Star bekomme... So, nachdem Du Deine Meinung kund getan hast und ich meine, können wir uns wieder ignorieren? Grüße [ - Antworten - Zitieren - Direktlink - ] |
|
25.07.2009, 16:38 Uhr whose Posts: 2156 Nutzer |
Also zuerst mal, ich finde den Thread hier äußerst lehrreich... ich stelle fest, daß ich in der langen Zeit, in der ich auf die "weit größeren Fähigkeiten eines Compilers in Sachen Optimierung" vertraut habe, eine Menge verlernt habe  Zu dem Disput: Wie wäre es, wenn ihr Euch darauf einigt, daß jolo derjenige mit der größeren Erfahrung in Sachen Assembler (sichtbar bisher nur M68K/AmigaOS, aber vielleicht auch für andere CPUs/OSse?) ist, wohingegen Holger derjenige ist, der die größere Erfahrung im Umgang mit höheren Programmiersprachen und deren Modellen, vor allem Java & Co., mitbringt? Eventuell vereinfacht sich der Umgang miteinander dann etwas, vor allem, wenn jeder den Erfahrungsschatz des anderen respektiert, in seinen Beiträgen berücksichtigt und damit Mistverständnissen wie z.B. "4 Gigabyte" zumindest ein wenig vorbeugt... Grüße -- ---  µA1 PPC 750GX-800 A4000 PPC 604e-233[ - Antworten - Zitieren - Direktlink - ] |
|
25.07.2009, 20:43 Uhr jolo Posts: 110 Nutzer |
@whose:Zitat: Das wird vielen so gehen, mir auch. Kniffe die wir früher aus dem Effeff beherrschten, haben wir verlernt, jedenfalls ich für meine Person zum Großteil. Zum angeblichen Disput. Es gibt keinen. Ich ignoriere Holgers Beiträge normalerweise. Zudem geht es nicht darum, wer was besser kann. Schwanzvergleiche sind was für männlich pubertierende Kinder - aus dem Alter sind wir raus. Holger wird viele Dinge in Sachen Programmierung besser können als ich. Das stört mich nicht, noch weckt das meinen Neid. Es wäre auch komisch wenn es anders herum wäre. Ich bin nach wie vor ein Hobby-Programmierer (und noch dazu ziemlich faul) der seine Brötchen mit ganz anderen Sachen verdient. Was mich jedoch an Holgers Beiträgen stört, sind die darin auftauchenden emotionalen Ausbrüche und der Rückgriff auf Strohmann-Argumente. Demnach werde ich weiter versuchen Holgers Beiträge zu ignorieren, egal was Du davon hältst. Sorry whose. Grüße [ - Antworten - Zitieren - Direktlink - ] |
|
25.07.2009, 22:37 Uhr AGSzabo Posts: 1663 Nutzer |
@jolo: > Kniffe die wir früher aus dem Effeff beherrschten, haben wir verlernt, jedenfalls ich für meine Person zum Großteil. haha, ich bekomme antworten und finde lösungen im halbschlaf, sehe programmzeilen vor dem inneren auge! -- e-uae 39bb2 - A4000d 39bb2 - Cyberst.MK3 060 50mhz 128mb - Cybervis. - Ariadne_II - ide DVD und 320gb HD (nur 128gb) - HD Floppy -- A500 3.1 adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110 [ - Antworten - Zitieren - Direktlink - ] |
|
26.07.2009, 18:51 Uhr Thore Posts: 2266 Nutzer |
Zitat: Warum terminierst du auf 3 Nullen? Antwort: Ist nicht nötig, war nur zu Fehlervermeidung drin, für die Schleife (falls die zu weit geht), natürlich kannst auf eine Null den String terminieren. Wie gesagt, war auch nur Code from the scratch und nix optimiert oder aufgeräumt. Und ist 68000 Code, die Version für 020+ kommt eben aus dem Zahlenbereich raus. Aber man sieht, auch auf dem 68000 sind Werte bis 655359 möglich. Kommt immer drauf an was man machen will. Sorry für die verspätete Antwort [ - Antworten - Zitieren - Direktlink - ] |
|
26.07.2009, 21:38 Uhr Blackbird Posts: 634 Nutzer |
@jolo: Zum angeblichen Disput. Es gibt keinen. Ich ignoriere Holgers Beiträge normalerweise. Ich fände es interessant welcher Schwanz nun größer ist, der Valueschwanz oder der Dezimaldödel  Zumal jeder weis, das bei Frauen 20cm zwischen ordinären 10 Zentimetern oder gar bis 40 Zentimeteren reichen kann. Männer schätzen das ohnehin wesentlich besser per Bierauge ein  Das ist wie bei Anglern wenn man sie nach der Länge des gefangenen Fisches fragt, da bekommt man dann auch "ganz gezielte Angaben"   Also, mal Butter bei die Fische: Wie lang ist "Value" und wie lange "Dezimal" ?   -- regards Blackbird PerfectPaint : supportOS4@amiforce.de HP: http://perfectpaint.amiforce.de/ Have also a look at my personal Website: http://www.blackbird-net.de [ - Antworten - Zitieren - Direktlink - ] |
|
10.08.2009, 21:07 Uhr Holger Posts: 8116 Nutzer |
Zitat:Die ursprüngliche Routine habe ich durchaus verstanden. Allerdings werden dort nirgendwo Divisionen eingespart. Divisionen einzusparen wurde erst von Dir vorgeschlagen. Zwar bezweifle ich, dass die Einsparungen die Menge an Subtraktionen und Iterationen wett machen können, allerdings stellt Dein letzter code in der Tat eine deutliche Verbesserung gegenüber dem ursprünglichen code dar, der ja Divisionen und Subtraktionen in unzähligen Iterationen enthielt und trotzdem nicht mit 32 Bit-Zahlen umgehen konnte. Zitat:Da der Threaderöffner ja laut eigener Aussage nicht an Lösungen interessiert war, sondern nur aus Spaß an der Freude diskutieren wollte, war es ausreichend, ihm Lösungsansätze aufzuzeigen, die natürlich in letzter Konsequenz überflüssig waren, weil er ja inzwischen RawDoFmt benutzt, was für ein GUI-Projekt, das auf hauptsächlich Systemen mit truecolor-Grafikkarten (insb. UAE und AOS4) läuft, vielleicht die auch beste Wahl ist. Zitat:Die Lösung, die Du gepostet hast, ist durchaus sinnvoll, wenn es darum geht, auf einem 68000, also nicht 68020+, eine 32 Bit Zahl zu formatieren. Wenn man von dieser speziellen Anforderung absieht, von der nie gesagt wurde, dass sie gebraucht werden würde, gibt es den 08/15-Standardalgorithmus, der sowohl das kann, was der ursprüngliche Code konnte (16 Bit-Zahlen auf 68000), als auch 32 Bit-Zahlen auf 68020+ formatieren kann, und um Welten effizienter arbeitet (und auch zusätzlich optimiert werden könnte). Da man auf diesen Standardalgorithmus von selbst kommen kann, haben eben einige erst einmal Hinweise statt vorgekauten code gepostet. Und gefragt, wie man auf diesen absurden (ursprünglichen) Code kommt. Zitat:Parat haben und jemandem vorkauen, der alle paar Tage mit einer neuen Frage dieser Art kommt, sind zwei verschiedene paar Schuhe. Inzwischen wurden sowohl Dein spezieller 68000-Code für 32 Bit-Zahlen, als auch der Standard-Algorithmus dem Threaderöffner vorgekaut, der ohnehin jetzt RawDoFmt verwendet. Wenn Du Dir jetzt den Thread noch mal in Ruhe anschaust, wirst Du feststellen, dass ich den Threaderöffner mehrfach danach gefragt habe, worauf es ihm eigentlich wirklich ankommt, eben weil ich ihm durchaus Lösungen anbieten kann, aber eben keine Lust dazu habe, Perlen vor die Säue zu werfen, wie es hier erneut geschehen ist. Natürlich hätte man auch sofort "Benutz das Betriebssystem!" schreiben können, dass wäre allerdings, auch wenn es das ist, was er jetzt letztendlich tut, auch wieder als Arroganz ausgelegt worden. Zitat:Wie Du willst. Zitat:Nö. Eine solche Einigung ist weder nötig, noch sinnvoll. jolo hat offensichtlich den ursprünglichen geposteten Code mit einem bestimmten Code für die spezielle Anforderung 32 Bit-Zahlen auf 68000 zu formatieren verglichen und ist zu dem (durchaus richtigen) Schluss gekommen, dass ihm nur geringfügige Teile dazu fehlen, und dabei übersehen, dass diese Anforderung weder genannt, noch von dem ursprünglichen Code erfüllt wurde. Außerdem hat er offenbar deutlich seltener auf AGSzabo's bisherige Anfragen ist diesem Forum geantwortet und deshalb noch nicht die Lust am Vorkauen verloren. Vielleicht kann er ja jetzt vielleicht doch erkennen, warum alle vor ihm postenden den ursprünglichen code als ineffizient und unsinnig abgestempelt haben und warum keiner Lust zum Lösungen vorkauen hatte. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
11.08.2009, 07:42 Uhr AGSzabo Posts: 1663 Nutzer |
@Holger: "nur aus spass and er freue zu diskutieren" ist nicht richtig. ich brauche (für mein hobby) die lösung schon. rawdofmt geht, aber jetzt benutze ich wiederum die funktion von jolo! (und habe ihn in meinem readme creditiert) ps: ich versteh nicht wieso das hier ein austausch-forum ist, aber viel fragen als unanständig gillt... pps: "vor allem auf grafikkarten" stimmt auch nicht. ich habe sogar ein config-flag "4 color mode", bei dem nach einem schema die 4 ersten pens in die uebrigen gemappt werden (zB tabspen = backpen). -- Sam os4.1, e-uae 39bb2 - A4000d 39bb2 - Cyberst.MK3 060 50mhz 128mb - Cybervis. - Ariadne_II - ide DVD und 320gb HD (nur 128gb) - HD Floppy -- A500 3.1 adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110 [ Dieser Beitrag wurde von AGSzabo am 11.08.2009 um 08:10 Uhr geändert. ] [ Dieser Beitrag wurde von AGSzabo am 11.08.2009 um 08:16 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
11.08.2009, 21:54 Uhr Holger Posts: 8116 Nutzer |
Zitat:Fragen stellen und Fehler in Assemblercode suchen lassen sind zwei völlig verschiedene Dinge. Außerdem stellst Du alle naselang Fragen, die an Deiner Behauptung, Du würdest die Dokumentation lesen, Zweifel aufkommen lassen. Außerdem gilt auch für Programmierfragen, dass man vom Fragesteller erwartet, vernünftige Informationen zum Problem herauszurücken, statt die anderen raten zu lassen. Wir wissen immer noch nicht, warum wir nun einen Fehler in dem von Dir geposteten Assemblercode suchen sollten, den Du noch nicht einmal selbst geschrieben hast, obwohl ein einfacher Aufruf von RawDoFmt, oder jede andere Lösung, die den nicht funktionierenden Code ersetzt hätte, es auch getan hätte. Oder warum Du nicht selbst versucht hast, eine entsprechende Funktion zu schreiben. Zitat:Und warum sollen wir das erraten? Ist es zu viel verlangt, zu schreiben, dass der Code selbst noch auf einem A500 laufen können soll? Wieso kannst Du das nicht einmal auf Nachfrage schreiben? mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
11.08.2009, 22:03 Uhr AGSzabo Posts: 1663 Nutzer |
@Holger: Entschuldige meine Dummheit ich tue was ich kann. Ich bin kein "grosser coder" und habe selber jede menge bugs. Trotzdem glaue ich, dass die Community hier funktionieren kann. Und ja, es soll sogar auf a500 (mit 3.1 soft oder hard rom) laufen. Hat mich keiner gefragt und jeden Aspekt meines projekts zu nenne ist mehr als mir bewusst ist! Du Musst nix raten, blos mich fragen. danke für deine hinweise -- Sam os4.1, e-uae 39bb2 - A4000d 39bb2 - Cyberst.MK3 060 50mhz 128mb - Cybervis. - Ariadne_II - ide DVD und 320gb HD (nur 128gb) - HD Floppy -- A500 3.1 adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110 [ - Antworten - Zitieren - Direktlink - ] |
|
14.08.2009, 15:20 Uhr jolo Posts: 110 Nutzer |
@HolgerZitat: Hier missverstehen wir uns. In der ursprünglichen Version werden Divisionen durch Subtraktionen ersetzt. Ich gebe zu, dass dies nicht ganz offensichtlich ist. Dennoch, die schon optimierte und ursprüngliche Version sah so aus: code:.2 addq.w #1,d4 sub.w d3,d0 bpl.s .2 add.w d3,d0 divu.w #10,d3 add.w #$30,d4 und wurde als Ersatz gewählt für: code:.2 divu.w d3,d0 ; d3 = 10000, 1000, 100, 10, 1 move.w d0,d4 ; Wert retten (Quotient) clr.w d0 ; Untere 16 Bits löschen (keine Hausnummern) swap d0 ; Restwert (Remainder) in untere 16 Bits divu.w #10,d3 ; 10000 zu 1000 usw. add.w #$30,d4 ; ASCII Demnach hat der Autor langsame Divisionen vermieden. "divu Dx,Dx" kostete eine 68000er 126 Taktzyklen, falls ich das noch recht in Erinnerung habe. Selbst eine 68060 braucht noch deren 22, 68020/68030 46 Taktzyklen und eine 68040 28 Taktzyklen. Alle Angaben ohne Gewähr. Wie schon mal angesprochen, mein letztes Assembler-Projekt liegt Jahre zurück... Falls meine Angaben aber annähernd richtig sind, würde selbst eine 68060 den so optimierten Code oft genug schneller ausführen als irgendeinen, der auf Divisionen fußen würde, denn jede Subtraktion kostet eine 68060 gerade einmal einen Taktzyklus, macht summa summarum maximal 10 Taktzyklen pro Durchlauf und nicht 22. Im besten Fall sogar nur einen Taktzyklus. code: Bei der 680x0 Assembler-Programmierung sollte der Programmierer einen ungefähren Überblick über die verschwendeten (?) Taktzyklen haben, ansonsten kann man sehr schön in 680x0 langsameren Code schreiben als der, der von irgendeinem Compiler generiert wird (hier im Thread wurde schon darauf hingewiesen). Nachteilig bei einem Multitasking Betriebssystem ist, dass die Abarbeitung des betreffenden Codes zu jederzeit unterbrochen werden kann was uns dann unter Umständen einen Strich durch die sorgsam gemachte Rechnung macht. Also ist das was ich oben aufgeführt habe nur Theorie die auch bestimmten Annahmen macht, z.B. dass die Branch-Vohersage beim erstenmal versagt (7 Taktzyklen, könnte ja auch gelingen...), ab dem zweiten Durchlauf klappt (0 Taktzyklen) und beim letzten Durchlauf einen Taktzyklus benötigt. Müsste das Kapitel im 68060 User Guide nachschlagen um mich wieder fit zu machen... Hab' dazu allerdings keine Lust. Zitat: Ich denke, dass der jetzt vorhandene Code, welcher die Subtraktionsmethode mittels einer Langwort-Tabelle durchführt, einen guten Kompromiss für alle MC680x0 Prozessoren darstellt. Siehe Taktzyklen-Auflistung oben - falls die von mir genannten Anzahlen an Taktzyklen annähernd stimmen, wovon ich allerdings ausgehe. Zitat: Ich sehe das Ganze etwas gelassener als Du. Wenn ich keine Lust habe auf Fragen einzugehen, werde ich mir auch nicht die Mühe machen, darauf zu antworten. Zudem ist gerade die Amiga-Programmierung recht schwierig weil es keine ausreichende, geschweige denn deutsche Dokumentation gibt. Für diejenigen, die seit mehr als 20 Jahren hin und wieder für das Amiga-OS programmieren, erscheint alles irgendwie logisch und ineinandergreifend. Für andere, die erst sehr viel später dazu gekommen sind gibt es aber viel zu viele Fragezeichen die auch nicht mittels der bestehenden Dokumentation aufgelöst werden können. Und die Zeiten als man alles selber bis ins kleinste Detail ausprobiert hat, d.h. disassemblieren bis zum Abwinken und dann eigene Test-Codes schreiben, sollten passé sein. Jetzt gibt es das bequeme Internet und Foren in denen man Fragen stellen kann und auch soll. Zitat: Die Fragestellung war ob der betreffende, noch nicht modifizierte Code für Langworte angepasst werden könnte (Zahlen größer 99999). Zitat: Dies habe ich in Form des 68020(+) leicht geänderten Code-Snippets gepostet und als Anmerkung eine Alternative für 68000er genannt. Demnach ist meinem Erachten nach die Fragestellung befriedigend beantwortet worden. @AGSzabo Zitat: Das ist zwar ein netter Zug von Dir aber gar nicht nötig weil ich nicht der Autor der von Dir beschriebenen Routine bin. Zum anderen würde ich persönlich nur Menschen erwähnen, die einen wirklichen Beitrag zu einem Projekt geleistet hätten. Würde Dein Projekt ohne meine Anmerkungen nicht laufen? Siehst Du. Demnach kannst Du mich getrost aus Deinen Credits löschen. Grüße [ - Antworten - Zitieren - Direktlink - ] |
|
14.08.2009, 15:36 Uhr AGSzabo Posts: 1663 Nutzer |
@jolo: Ob du die routine selbst schreibst oder mir anders beschaffst ist mir eigentlich egal (das kann man ja auch extra mit angeben). Selbstverstälich halte ich mich an die wünsche der helfer ob jemand genannt werden will oder nicht. die sind leider nicht immer eindeutig. zuviel ist imo bsser also zu wenig. man soll sehen wieviele leute ein projekt interessiert. ich mumbele herum ob ich xui open source machen soll, aber auf jeden fall zu "contrib-ware" wo man ne funktion oder etas zum projekt beisteuern kann wenn man es mag. ps: ich komme zum teil aus der demoscene, da sind umfassende credits und greetings eine regel.  -- Sam os4.1, e-uae 39bb2 - A4000d 39bb2 - Cyberst.MK3 060 50mhz 128mb - Cybervis. - Ariadne_II - ide DVD und 320gb HD (nur 128gb) - HD Floppy -- A500 3.1 adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110 [ Dieser Beitrag wurde von AGSzabo am 14.08.2009 um 15:46 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
14.08.2009, 17:25 Uhr Holger Posts: 8116 Nutzer |
Zitat:Ja, das ist es, was eben auf Unverständnis stieß. Es gibt einen naheliegenden Algorithmus, der so schon im Schulunterricht beschrieben wird (falls Dezimalkonvertierung überhaupt ein Thema ist), und vor allem, auf den eigentlich jeder selbst kommen kann. Der besteht einfach darin, so lange durch zehn zu dividieren, bis man null erhält und den jeweiligen Rest von rechts nach links hinzuschreiben. Insbesondere, wenn man in Assembler programmiert, wo man Quotient und Rest in einer Operation bekommt, sehr kompakt. Die Anzahl der Divisionen ist gleich der Anzahl sichtbarer Stellen, wenn man den Algorithmus etwas umformt, auch eine weniger. Wenn man dies im Hinterkopf hat, kommt man kaum darauf, dass ein Algorithmus, der im Schnitt mehr Divisionen durchführt, Divisionen einsparen würde. Gegenüber dieser Variante gab es zwei mögliche Alternativen, um die ursprüngliche Fragestellung zu beantworten. Entweder man ersetzt diesen durch einen anderen Code, wie z.B. den Standardalgorithmus, von dem man hoffen kann, dass der Fragesteller ihn versteht, der aber den Nachteil hat, nicht auf 68000 zu funktionieren. Oder man versucht, eine 68000-kompatible Lösung zu finden. Da gibt es bestimmt auch noch mehr als Deine. Zitat:Moment, Du vergleichst Deine Variante mit dem ursprünglichen Code. Und gehst offenbar von 16 Bit aus. Der Algorithmus, der von mir und Thore gepostet wurde, iteriert nur über die sichtbaren Stellen, benötigt also nur eine Division pro sichtbarer Stelle. Ist also sehr wohl von der zu formatierenden Zahl abhängig. Wenn wir von 32-Bit-Formatierung ausgehen, benötigt die Formatierung der Zahl "0" nach dem simplen Algorihtmus lediglich eine Division, (die man auch noch wegoptimieren kann), d.h. nach Deinen Angaben 44 Taktzyklen für Long-Division, während der andere Algorithmus über alle Stellen iteriert also so lange braucht, wie von Dir für Ascii-Ziffer 0 angegeben, also 9 Zyklen, auch wenn nichts geschrieben wird. Macht bei zehn Stellen 90 Zyklen. Also ist der einfache Algorithmus bei kleinen Zahlen, die meiner Meinung nach häufiger vorkommen, effizienter. Bei großen Zahlen kippt das zwar, aber Du hast ja auch den restlichen Overhead unter den Tisch fallen lassen. Der einfachere Algorithmus kommt z.B. ohne zusätzlichen Test auf "0" aus. Vor allem aber habe ich ja von Anfang an betont, dass da nichts optimiert ist und auch Vorschläge zur Optimierung gemacht. Einer war z.B. zwei Stellen auf einmal zu verarbeiten. Eine Division durch 100 würde gegenüber dem worst case der Subtraktionsmethode, also 18 Iterationen für "99", deutlich besser aussehen. Und man könnte beim Erreichen von fünfstelligen Zahlen auf 16Bit-Divisionen wechseln oder den Trick mit dem Ersetzen von Divisionen durch Multiplikationen einsetzen. Wenn es um Performanceoptimierung geht, gibt es noch wesentlich mehr Potential. Viele Iterationen sind selten die optimale Lösung. Zitat:Das Risiko hat jeder Code. Aber natürlich verringert sich das Risiko, je weniger Taktzyklen man braucht. Deine Rechnung bleibt also relevant. Zitat:Bei Schleifen, bzw. Rückwärtssprüngen gilt normalerweise die Annahme, dass sie stattfinden, die Vorhersage versagt dann nur beim letzte Mal, und auch dass nur, wenn die CPU keine weitere Heuristiken besitzt. Wie's beim 68060 konkret aussieht, weiß ich nicht. Halte ich auch nicht für so wichtig, weil die Performance auf den älteren Rechnern wichtiger wäre. Zitat:Mir erscheint er auch als guter Kompromiss. Aber ich bin sicher, dass es noch deutlich effizienter gehen würde, wenn man das wollte. Zitat:Ähem, hier wurde geantwortet, weil man antworten wollte. Es sah nur so aus (sieht eigentlich immer noch so aus), als hätte hier jemand einen Code, den er selber nicht versteht, gepostet, um sich jetzt eine Variante zum Benutzen einzuholen, die er immer noch nicht versteht, ohne jegliches Interesse daran zu haben, es wirklich zu verstehen. Ich glaube, die meisten hier dachten, wenn jemand in Assembler programmiert, hat er auch Interesse daran, das Ganze auch zu verstehen. Deshalb wurde gefragt, warum der Code so aussieht, und versucht, den Fragesteller in eine Richtung zu lenken, die ihn selbst in die Lage versetzt, besseren Code zu schreiben. Daran bestand offensichtlich kein Interesse. Aber genau das lässt alles so sinnlos erscheinen. Zitat:Ja, aber wenn wir schon code für andere schreiben, warum müssen wir dann ausgerechnet eine weitere überflüssige GUI-Bibliothek programmieren? mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
16.08.2009, 14:40 Uhr Holger Posts: 8116 Nutzer |
Just for fun... Hier eine optimierte Fassung der "Dividiere durch zehn, bis null erreicht ist"-Variante: code:; ; d0 - unsigned 32 Bit value ; a0 - target buffer (up to 11 bytes required) ; restores all registers _itoa movem.l d0-d6/a1/a2,-(a7) lea .sizes(pc),a1 .getSize addq.l #1,a0 cmp.l (a1)+,d0 bhi.s .getSize moveq.l #1,d3 moveq.l #100,d4 swap d3 ; 65536 clr.b (a0) ; zero terminated (C-style) cmp.l d3,d0 bcs.s .skipBigLoop lea .oneDigits(pc),a1 lea .tenDigits(pc),a2 .bigLoop divul.l d4,d1:d0 move.b (a1,d1.w),-(a0) move.b (a2,d1.w),-(a0) cmp.l d3,d0 bhi.s .bigLoop .skipBigLoop move.l #52429,d3 ; 1/10 ~ moveq.l #19,d4 ; 52429/2^19 moveq.l #"0",d6 .smallLoop move.l d0,d5 mulu.l d3,d0 lsr.l d4,d0 ; d0/=10 move.l d0,d1 move.l d0,d2 lsl.l #3,d1 add.l d2,d2 add.l d2,d1 ; d1=d0*10 sub.l d1,d5 ; d5-=d1 => 0..9 or.b d6,d5 ; d5|="0" move.b d5,-(a0) tst.l d0 bne.s .smallLoop movem.l (a7)+,d0-d6/a1/a2 ; a0 has same value as before rts .tenDigits dc.b "00000000001111111111222222222233333333334444444444" dc.b "55555555556666666666777777777788888888889999999999" .oneDigits dc.b "01234567890123456789012345678901234567890123456789" dc.b "01234567890123456789012345678901234567890123456789" .sizes dc.l 9, 99, 999, 9999, 99999, 999999, 9999999 dc.l 99999999, 999999999, 4294967295 Wie gehabt, benötigt die Routine um so weniger Taktzyklen, je kleiner die zu formatierende Zahl ist, genauer, je weniger sichtbare Stellen sie hat. Der worst case liegt jetzt aber bei insgesamt drei Divisionen, für Zahlen kleiner als 65536 werden gar keine Divisionen mehr benötigt. Die benötigten Zyklen pro Stelle liegen deutlich unter dem worst-case der Subtraktionsmethode, je nach CPU sogar unter dem best case. Nun ja, für 68020 oder höher. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
| 1 -2- | [ - Beitrag schreiben - ] |
| amiga-news.de Forum > Programmierung > value to dezimal string | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|