amiga-news 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 - ]

22.07.2009, 22:27 Uhr

AGSzabo
Posts: 1663
Nutzer
bei mir drehn sich die räder, so stark erfinde ich sie neu! daher hier eine routine, die einen zahlwert zu einem text umrechnet. natürlich, wer hätte es anders gedacht, sie funtioniert nicht richtig! offenbar liegt es daran dass meine eingabe zahlen zu groß waren? nunja, auf langwortgröße sollte es schon funtionieren. wer weis wie?

code:
;d0	;value 0 to 99999 (?)
;a0	;*deststring
;>a0	;*behindnewchars

ValToDez:
	movem.l	d2-d4/a1,-(a7)
	push	a0
	moveq	#4,d1
	move.l	#10000,d3
	moveq	#0,d2
.lp1	moveq	#-1,d4
.2	addq.w	#1,d4
	sub.w	d3,d0
	bpl.s	.2
	add.w	d3,d0
	divu.w	#10,d3
	add.w	#$30,d4
	tst.w	d2
	bne.b	.4
	cmp.b	#"0",d4
	beq.b	.5
	st	d2
.4	move.b	d4,(a0)+
.5	dbf	d1,.lp1
	cmp.l	(a7)+,a0
	bne.b	.pop
	move.b	#"0",(a0)+
.pop	movem.l	(a7)+,d2-d4/a1
	rts

;d0.w	;number of chars
;a0	;*string
;>d0	;value

DezToVal:
	movem.l	d1-d3/a0,-(a7)
	lea	(a0,d0.w),a0
	subq.w	#1,d0
	moveq	#1,d2
	moveq	#0,d3
.dv_lp	moveq	#0,d1
	move.b	-(a0),d1
	sub.w	#$30,d1
	mulu.w	d2,d1
	mulu.w	#10,d2
	add.l	d1,d3
	dbf	d0,.dv_lp
	move.l	d3,d0
	movem.l	(a7)+,d1-d3/a0
	rts


ich habe zum spass noch die gegenteilige rountine mit angegeben, die einen string in einen wert umrechnet...
--
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 - ]

23.07.2009, 17:53 Uhr

Holger
Posts: 8116
Nutzer
Da kräuseln sich einem ja die Zehnägel hoch. Vielleicht schreibst Du das mal besser in einer Hochsprache oder Pseudocode hin, bevor Du anfängst, es in Assembler zu implementieren. Abgesehen von der Fehlerträchtigkeit, warum machst Du das überhaupt in Assembler? Effizient ist das, was Du da verzapft hast, bestimmt nicht.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

23.07.2009, 23:24 Uhr

DieterG
Posts: 164
Nutzer
Naja, interessante vorgehensweise, aber ich finde so lernt man noch am besten, also nicht immer alles so verteufeln.
Optimal ist der Code wirklich nicht, oder die vorgabe war wie verballere ich möglichst viele Register in wenig Code, und nicht geschwindigkeit.
Interessant finde ich, wie im code daurend zwischen wort und byte-werten und -vergleichen gewechselt wird, ohne das sich die eigentlichen werte aus dem bytebereich bewegen.
Aber aller anfang ist schwer, das wird schon noch, mathematisch ist das jedenfalls ein möglicher Lösungsweg, daran liegt es nicht.



[ - Antworten - Zitieren - Direktlink - ]

24.07.2009, 05:31 Uhr

AGSzabo
Posts: 1663
Nutzer
@DieterG:

Ich muss faiererweise (mir selbst gegenüber) anmerken dass diese routine NICHT von mir ist. Ich würde niemals worte statt bytes verschwenden.

And-i
--
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 - ]

24.07.2009, 10:08 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von DieterG:
Optimal ist der Code wirklich nicht, oder die vorgabe war wie verballere ich möglichst viele Register in wenig Code, und nicht geschwindigkeit.
Interessant finde ich, wie im code daurend zwischen wort und byte-werten und -vergleichen gewechselt wird, ohne das sich die eigentlichen werte aus dem bytebereich bewegen.

Mich hat vor allem die innere Zählschleife beeindruckt. Ansonsten ist es ein schönes Beispiel dafür, wie wenig die Performance letztendlich von der gewählten Programmiersprache abhängt, da die teuerste Operation die Division sein dürfte, und ein Algorithmus, der die Divisionen vermeidet, auch in einer Hochsprache implementiert, effizienter als dieser Assembler-Code sein dürfte.

Zitat:
Original von AGSzabo:
Ich muss faiererweise (mir selbst gegenüber) anmerken dass diese routine NICHT von mir ist.


Umso mehr ein Grund, den Algorithmus in einer abstrakteren Form aufzuschreiben. Dann kann man überprüfen, ob a) der Algorithmus korrekt ist, bzw. b) der Assemblercode tatsächlich diesen Algorithmus widerspiegelt.

Andernfalls sind es zu viele Fehlerquellen auf einmal, bzw. Du zwingt den potentiellen Helfern genau diese Arbeit auf, wenn sie den Fehler finden sollen.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

24.07.2009, 11:09 Uhr

AGSzabo
Posts: 1663
Nutzer
@Holger:

>Du zwingt den potentiellen Helfern genau diese Arbeit auf, wenn sie den Fehler finden sollen.

nah, von sollen kann nicht die rede sein. natürlich nur wer will.
--
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 - ]

24.07.2009, 11:25 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von AGSzabo:
nah, von sollen kann nicht die rede sein. natürlich nur wer will.

So hart sollte die Formulierung nicht rüberkommen. Ich gehe aber schon davon aus, dass Du gerne Hilfe bei diesem Thema hättest, sonst hättest Du diesen Thread nicht eröffnet. ;)

Und so, wie man bei anderen Fragestellungen erwartet, dass der Fragende zuerst versucht, das Problem selbst zu lösen und sich aus allgemein zugänglichen Quellen zu informieren, erwartet man natürlich auch bei Programmierproblemen, dass derjenige, der Hilfe haben möchte, bereit ist, die Dinge zu erledigen, die in seiner Macht stehen.

Und ich nehme doch mal an, dass Du Dich schon mit diesem Code beschäftigt hast, um den Fehler selbst zu finden. Also eigentlich müsstest Du schon Gedanken dazu gehabt haben, was der Code eigentlich tun sollte. Und die solltest Du aufschreiben.

Man könnte natürlich auch den Code komplett wegschmeißen, einen ordentlichen Algorithmus formulieren, und implementieren. Das wäre vermutlich dutzendmal leichter, als den existierenden Code zu analysieren. Aber wahrscheinlich nicht in Deinem Sinne, wenn Du lieber den Fehler in diesem Code finden willst, oder?

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

24.07.2009, 11:31 Uhr

AGSzabo
Posts: 1663
Nutzer
@Holger:

man könnte natürlich auch die mathematiklibraries vernweden, ich habe dort nachgesehn es gibt da konvertierungsfunktionen! und es wird an die matheatischen coprozessoren geschickt, die im zweifelsfall immer schneller sind.
--
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 - ]

24.07.2009, 12:06 Uhr

Thore
Posts: 2266
Nutzer
Am besten gehst du so vor:
1. Schreibtischtest, also auf ein Papier entwerfen und berechnen
2. ausformulieren
3. optimieren (Zeilentausch zwecks Register wait states, loop unroll, l->w wenns geht, add d0,d0 statt mulu #2,d0 etc pp...)
4. testen

Ich nehme an, das gehört auch zu deinem GUI Projekt. Vergiss dann nicht ins Copyright oder Author zu setzen "AGSzabo & many Amiga-News.de members" ;)

Wie willst Du denn den Zahlenwert haben? Als 32 Bit Integer oder Cardinal? (also Vorzeichenbehaftet oder nicht?)
Du hast bei 32 Bit die Zahlen 0 bis 4294967295 oder -2147483648 bis 2147483647 je nachdem ob du Vorzeichen verwendest oder nicht.
Oder willst Du quasi "unendlich" viele Stellen?

[ - Antworten - Zitieren - Direktlink - ]

24.07.2009, 12:30 Uhr

AGSzabo
Posts: 1663
Nutzer
@Thore:

> Vergiss dann nicht ins Copyright oder Author zu setzen "AGSzabo & many Amiga-News.de members" ;)

das steht schon seit jeher in meinem readme-file.

optimieren kann ich gut, bis auf waitstates, die muss man wissen. die zahlen sollen größer als ein wort sein können und auf bzw ab gerundet werden. ich bin sicher dass das mit der ffplibrary geht!

mit dem farb-voreinstell habe ich ein änliches problem: weil xui mit 24bit werten arbeitet, die in 96 bit oder zurück umgerechnet werden wenns nötig ist (teilen oder multiplizieren mit $01010101) und dabei kommt es zu rundungsfehlern. wenn ich zb AAAAAA eingebe, kann es sein dass nach einem update plötzlich aaaaa9 oder aaa9aa drin steht. bei machnen werten passiert es, bei manchen nicht ...
--
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 24.07.2009 um 12:33 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

24.07.2009, 12:38 Uhr

Thore
Posts: 2266
Nutzer
> optimieren kann ich gut, bis auf waitstates
Im Grunde kannst du Dir merken, wenn es geht nicht zweimal das gleiche Register nacheinander benutzen, da er evtl noch warten muss bis der Zugriff möglich ist.
Beispiel (willkürliche Berechnung):

move.l #4,d1
add.l #2,d1
move.l #5,d2
add.l d1,d2

ist besser so:

move.l #4,d1
move.l #5,d2
add.l #2,d1
add.l d1,d2

Wieso musst Du die 24Bit in 96Bit umrechnen?

[ Dieser Beitrag wurde von Thore am 24.07.2009 um 12:40 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

24.07.2009, 12:53 Uhr

AGSzabo
Posts: 1663
Nutzer
@Thore:

aha.

so, gut, umrechnen will ich 24 bit werte weil 24 bit ausreichend (ein byte pro r, g oder b) für uns sind in 96 bit werte weil die amiga farb-funktionen zur reservierung von stiften 96bit werte, r= $xxxxxxxx usw benutzen! das farbrad liefert umgekehrt auch 96 bit zurück die ich dann wieder in 24 bit umrechne. werte die in ein langwort passen sind in assmebler viel leichter zu handhaben und 96 bit sind sowieso quatsch.
--
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 - ]

24.07.2009, 17:30 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von AGSzabo:
ich bin sicher dass das mit der ffplibrary geht!

:dance3: Bisher ging es um die Konvertierung eines integer Wertes in einen Dezimalstring. Warum sollte die fastfloatingpoint-library dafür eine Funktion anbieten?
Zitat:
weil xui mit 24bit werten arbeitet, die in 96 bit oder zurück umgerechnet werden [...] kommt es zu rundungsfehlern.
Ist nicht nachvollziehbar...es sei denn, es hängt mit der oben erwähnten Problematik zusammen: benutze nicht floating point Bibliotheken für integer Operationen.

Du hast die Frage noch nicht beantwortet, worum es Dir primär geht, einen funktionierenden Algorithmus zu bekommen oder den Fehler in dem oben stehenden zu finden.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

24.07.2009, 17:48 Uhr

a-e-neumann
Posts: 5
Nutzer
> nunja, auf langwortgröße sollte es schon funtionieren. wer weis wie?

kommt mir recht umstaendlich vor.
Wenn der Zahlenbereich garantiert <100000 ist,
sollte das nicht durch eine simple Folge von

divu.w #10,d0

mit entsprechendem umladen von Ergebnis/Rest in andere Register gehen?

Vielleicht hilft auch das BCD Beispiel auf

http://margo.student.utwente.nl/el/micros/68xxx/

?
ffp.library ist nur fuer Motorola's seltsames FP format zu gebrauchen.
WIMRE gibt's aber in der amiga.lib Umwandlungsroutinen
von der Art atoi() (ASCII to integer),
habe aber leider dir RKMs grade nicht greifbar.

[ - Antworten - Zitieren - Direktlink - ]

24.07.2009, 17:57 Uhr

AGSzabo
Posts: 1663
Nutzer
Die FP-Bibliotheken bieten tatsächlich konvertierungsfunktionen ascii<->ffp an. das ist eine tatsache. mit etwas rumrotieren sollten die auch für integer gehen.

die frage, was ich lieber will ist so oder so gut. inzwischen bin ich aber mit dem programm schon viel weiter und verwende bis auf weiteres RawDoFmt().

das problem mit der 96 <> 24 bit umrechnung besteht tatsächlich, ich habe es gesehen.

--
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 - ]

24.07.2009, 18:02 Uhr

jolo
Posts: 110
Nutzer
@AGSzabo:

Hi.

Zitat:
...auf langwortgröße sollte es schon funtionieren. wer weis wie?

code:
ValToDez:
	movem.l	d2-d4/a1,-(a7)
	push	a0
	moveq	#4,d1
	move.l	#10000,d3
	moveq	#0,d2
.lp1	moveq	#-1,d4
.2	addq.w	#1,d4
	sub.w	d3,d0
	bpl.s	.2
	add.w	d3,d0
	divu.w	#10,d3
	add.w	#$30,d4
	tst.w	d2
	bne.b	.4
	cmp.b	#"0",d4
	beq.b	.5
	st	d2
.4	move.b	d4,(a0)+
.5	dbf	d1,.lp1
	cmp.l	(a7)+,a0
	bne.b	.pop
	move.b	#"0",(a0)+
.pop	movem.l	(a7)+,d2-d4/a1
	rts


Dieser Code wurde ursprünglich für eine 68000er CPU, bei der die Eingabe nie größer als 99999 ist, geschrieben.
Aber lass Dich nicht ins Bockshorn jagen; ineffizient ist der Code mitnichten!
Zudem unterdrückt er führende Nullen und testet auch korrekt ob 'd0' null ist, heißt, dann wird trotz Unterdrückung der führenden Nullen eine einzige Null in Deinen Puffer geschrieben. Leider wird der Puffer aber nicht NUL-Byte terminiert.

Alles in allem ist dies Standard-Code der in den 80er Verwendung fand.


Änderungen damit Langworte ausgegeben werden können; ausschließlich 68020(+):
code:
:
	moveq	#4,d1
	move.l	#10000,d3
in
	moveq	#9,d1
	move.l	#1000000000,d3
ändern.

Und die Instruktionen:
	sub.w	d3,d0
	bpl.s	.2
	add.w	d3,d0
	divu.w	#10,d3
gegen
	sub.l	d3,d0
	bpl.s	.2
	add.l   d3,d0
	divul.l	#10,d3:d3
tauschen.


Wie gesagt, 68020+ ist Voraussetzung.

Wenn Du diesen abgeänderten Quellcode für 68000 kompatibel machen willst, musst Du nur 'd3' mittels Werten einer Tabelle (beginnend mit 1000000000 und endend bei 1) aktualisieren, dann entfällt auch 'divu.w' bzw. 'divul.l'.


Grüße

[ - Antworten - Zitieren - Direktlink - ]

24.07.2009, 18:07 Uhr

AGSzabo
Posts: 1663
Nutzer
@jolo:

ah, da sind die profis. geht doch! :-)
--
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 - ]

24.07.2009, 19:31 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von AGSzabo:
Die FP-Bibliotheken bieten tatsächlich konvertierungsfunktionen ascii<->ffp an. das ist eine tatsache. mit etwas rumrotieren sollten die auch für integer gehen.

Und wo liegt der Sinn angesichts einer Fülle von bereits existierenden Funktionen, die direkt für integer gedacht sind?
Zitat:
Original von jolo:
Aber lass Dich nicht ins Bockshorn jagen; ineffizient ist der Code mitnichten!

Doch, und es wurde auch bereits erklärt, warum.
Zitat:
Zudem unterdrückt er führende Nullen und testet auch korrekt ob 'd0' null ist, heißt, dann wird trotz Unterdrückung der führenden Nullen eine einzige Null in Deinen Puffer geschrieben.
Das ist ja auch eine Mindestanforderung.
Zitat:
Alles in allem ist dies Standard-Code der in den 80er Verwendung fand.
Das ist kein Qualitätsmerkmal.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

24.07.2009, 22:23 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von jolo:
Wenn Du diesen abgeänderten Quellcode für 68000 kompatibel machen willst, musst Du nur 'd3' mittels Werten einer Tabelle (beginnend mit 1000000000 und endend bei 1) aktualisieren, dann entfällt auch 'divu.w' bzw. 'divul.l'.

:lach: Den habe ich ja ganz übersehen. Klasse Vorschlag, Division durch eine Tabelle mit einer Milliarde Einträgen zu "optimieren". Dass es dann auch auf einem 68000 läuft, ist angesichts des Speicherbedarfs von schlappen 4GB natürlich sehr nützlich...

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

24.07.2009, 22:49 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von AGSzabo:
ah, da sind die profis. geht doch! :-)

Was geht doch?
Ich habe Dich zwei mal gefragt, ob Du einen funktionierenden Algorithmus haben willst, oder nur den Fehler im angegebenen. Du warst nicht in der Lage, Dich vernünftig zu artikulieren. Jetzt musste also jemand für Dich erraten, dass es für Dich ok ist, wenn der Code einen 68020er voraussetzt, und es Dir offenbar nicht darum geht, den Code zu verstehen.
Das hättest Du auch deutlich eher haben können...

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

24.07.2009, 23:03 Uhr

AGSzabo
Posts: 1663
Nutzer
@Holger:

> Was geht doch?

die antwort war gut, ich bleibe dabei. ob ich dann den 20er code nutze oder nicht ist egal. mir war nur nach spass und dem verstehen mit den zahlen und zeilen... man kann auch über algos diskutieren ohne das ich da gleich eine lösung auf keine große frage will und das machen wir doch!
--
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 - ]

24.07.2009, 23:11 Uhr

Holger
Posts: 8116
Nutzer
Boah, jetzt habe ich den Code mal debugged, weil ich ihn anders kaum verstehen konnte, und musste feststellen, dass er noch ineffizienter ist, als ich dachte.

Allein schon, wenn man ihn anweist, den Wert 0 in einen String umzuwandeln...was diese Routine an unnötigen Code durchläuft. Von 99999 im Single-Step ganz zu schweigen :D

Wenn 68020 ok ist, dann macht folgender Code das richtige:
code:
;
	; d0 - unsigned 32 Bit value
	; a0 - target buffer (up to 11 bytes required)
	; restores all registers
_itoa
	movem.l	d0-d3/a1,-(a7)
	lea	.3(pc),a1
.1
	addq.l	#1,a0
	cmp.l	(a1)+,d0
	bhi.s	.1

	clr.b	(a0)	; zero terminated (C-style)
	moveq.l	#10,d3
	moveq.l	#"0",d2
	move.l	d0,d1
.2
	divul.l	d3,d0:d1
	or.b	d2,d0
	move.b	d0,-(a0)
	move.l	d1,d0
	bne.s	.2

	movem.l	(a7)+,d0-d3/a1	; a0 has same value as before
	rts
.3
	dc.l	9, 99, 999, 9999, 99999, 999999, 9999999
	dc.l	99999999, 999999999, 4294967295


Ist auch nicht sonderlich optimiert, führt aber zumindest keine Tonnen von unnützen Schritten aus.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

24.07.2009, 23:21 Uhr

Thore
Posts: 2266
Nutzer
Ich hab mal eben was ausprobiert, scheint für Zahlen bis 655539 zu klappen.
Großere gehen nicht hier, da ich divu verwende (welcher als Ergebnis ein Word hat)
Da nach der ersten Teilung ich Word hab hab ich eben 65535 als größte Zahl plus die hinterste Stelle.

Der Code ist scratchcode und weder optimiert noch sonstwas.
Hab die Textausgabe-Routine auch gleich mit drangeschrieben, dann
kann mans gleich ausprobieren. Die Länge muss oben dementsprechend
angepasst werden. Hier im Demo hab ich die größtmögliche Zahl drin

Wer genau wissen will warum das nun eine Dezimalzahl in einen String
wandelt soll sich melden.

move.l #655359,d0
move.l #0,d1
move.l #6,d2 ; Länge

move.l d2,len

lea Str(pc),a2
add.l d2,a2
sub.l #1,a2

; Anfang Algorithmus
.loop:
divu #10,d0
move.w d0,d1
swap.l d0
add.b #48,d0
move.b d0,(a2)
sub.l #1,a2
move.l d1,d0
dbra d2,.loop
;Ende Algorithmus

; Textausgabe
move.l 4,a6
lea.l dosname(pc),a1
moveq #0,d0
jsr -552(a6)
tst.l d0
beq error
move.l d0,dosbase
move.l dosbase,a6
jsr -60(a6)
move.l d0,d1
move.l #Str,d2
move.l len,d3
jsr -48(a6)

move.l #4,a6
move.l dosbase,a1
jsr -414(a6)

error:
moveq #0,d0
rts

len: dc.l 0
dosname: dc.b 'dos.library',0,0,0
dosbase: dc.l 0
Str: dc.b 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

end

[ - Antworten - Zitieren - Direktlink - ]

24.07.2009, 23:24 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von AGSzabo:
mir war nur nach spass und dem verstehen mit den zahlen und zeilen... man kann auch über algos diskutieren ohne das ich da gleich eine lösung auf keine große frage will und das machen wir doch!

Ich weiß nicht, bislang haben wir nicht wirklich über den Algorithmus diskutiert. Du hast ihn laut eigener Aussage nicht geschrieben, nur gepostet, zwei haben gesagt, dass sie ihn ineffizient finden, einer meinte, das wäre nicht so.

Aber von wirklichen Verständnisfragen habe ich bislang nichts gesehen. Ich habe ihn in seiner Umständlichkeit erst beim schrittweise ausführen verstanden. Ob Du ihn verstanden hast, ob Du ihn genauso entworfen hättest, was Du anders gemacht hättest, davon weiß ich immer noch nichts.

Dafür hast Du jetzt einen alternativen Algorithmus zum vergleichen. Könnte vielleicht wirklich lehrreich sein. Und falls Du eine Anregung haben willst, wie man ihn wirklich optimieren kann:
  • Für große Zahlen durch hundert, statt durch zehn teilen und zwei Zeichen in einem Schritt schreiben, bis der Quotient klein genug für den nächsten Punkt geworden ist
  • Für kleine Zahlen nicht durch zehn dividieren, sondern mit (2^n / 10) multiplizieren und um n nach rechts shiften. Die Größe von n muss dabei geschickt gewählt werden.

    Der resultierenden Code wäre deutlich komplizierter als mein Beispiel oben, aber unterm Strich trotzdem deutlich schneller.

    So, jetzt gehe ich aber in den Urlaub...

    mfg

    --
    Good coders do not comment. What was hard to write should be hard to read too.

    [ - Antworten - Zitieren - Direktlink - ]

  • 24.07.2009, 23:31 Uhr

    Holger
    Posts: 8116
    Nutzer
    Zitat:
    Original von Thore:
    Wer genau wissen will warum das nun eine Dezimalzahl in einen String
    wandelt soll sich melden.

    Ist ja im Prinzip das gleiche wie meins, nur dass ich auch die Größe ermittle, diese also nicht übergeben werden muss.
    Na ja, und ich habe meinen schnell noch angepasst, als ich gesehen habe, dass es auch 68020 sein darf ;)
    Vorher hatte ich natürlich das gleiche Limit nach oben.

    mfg

    --
    Good coders do not comment. What was hard to write should be hard to read too.

    [ - Antworten - Zitieren - Direktlink - ]

    25.07.2009, 06:30 Uhr

    AGSzabo
    Posts: 1663
    Nutzer
    die 68020er routine ist mein favorit. aber die andere ist auch nicht schlecht, weil sie so kurz ist.

    aber wenn ich nicht vor habe 2 versionen meines programms zu veröffentlichen ist es nicht reatsam nur 68020++ code zu verwenden..


    >dosname: dc.b 'dos.library',0,0,0

    @thore: warum terminierst du mit 3 nullen? eine würde im nicht-even fall reichen, oder?
    --
    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 - ]

    25.07.2009, 12:00 Uhr

    jolo
    Posts: 110
    Nutzer
    @Holger

    Zitat:
    Den habe ich ja ganz übersehen. Klasse Vorschlag, Division durch eine Tabelle mit einer Milliarde Einträgen zu "optimieren". Dass es dann auch auf einem 68000 läuft, ist angesichts des Speicherbedarfs von schlappen 4GB natürlich sehr nützlich...

    Ich wollte auf Deine Beiträge nie wieder eingehen, jetzt muss ich es doch weil Du hier (gezielt?) Fehlinformationen verbreitest.

    code:
    ValToDez:
    	movem.l	d2-d4/a1-a2,-(a7)
    	push	a0		; Pufferstart merken
    	moveq	#10-1,d1	; 10 Stellen (wg. dbf -1)
    	lea	divtable(pc),a2	; Divisionstabelle
    	move.l	(a2)+,d3	; = 1000000000 f. ersten Durchlauf
    	moveq	#0,d2		; Flagge für führende Nullen
    .lp1	moveq	#-1,d4		; Zähler für Subtraktionen ohne Überlauf
    .2	addq.w	#1,d4		; plus 1 = im Bereich von 0 bis 9
    	sub.l	d3,d0		; Subtraktion
    	bpl.s	.2		; Solange kein Überlauf (bcc.s)
    	add.l	d3,d0		; Negativen (Überlauf!) Wert korrigieren
    	move.l	(a2)+,d3	; Neuen Wert aus Tabelle, entspricht d3 / 10
    	add.w	#$30,d4		; Nach ASCII wandeln
    	tst.w	d2		; Schon Ziffern in Puffer abgelegt?
    	bne.b	.4		; Falls ja, auch Nullziffer ablegen
    	cmp.b	#"0",d4		; Ist es eine Nullziffer?
    	beq.b	.5		; Falls ja, führende Null nicht ablegen
    	st	d2		; Sonst Flagge setzen
    .4	move.b	d4,(a0)+	; Ziffer ablegen
    .5	dbf	d1,.lp1		; Anzahl Stellen
    	cmp.l	(a7)+,a0	; Pufferadresse = initiale Adresse?
    	bne.b	.pop		; Wenn nicht,
    	move.b	#"0",(a0)+	; sonst Nullziffer ablegen (d0 war 0)
    .pop
    	clr.b	(a0)		; String Terminierung (Puffer muss 11
    				; Bytes groß sein)
    	movem.l	(a7)+,d2-d4/a1-a2
    	rts
    
    divtable
    	dc.l	1000000000
    	dc.l	100000000
    	dc.l	10000000
    	dc.l	1000000
    	dc.l	100000
    	dc.l	10000
    	dc.l	1000
    	dc.l	100
    	dc.l	10
    	dc.l	1


    Es ist echt schwierig so etwas 68000er kompatibel zu machen...
    Und ja, ich habe gerade 4 Gigabytes RAM verschwendet...


    @AGSzabo

    Zitat:
    ah, da sind die profis. geht doch! :-)

    Ich bin kein Profi, nur ein Einäugiger unter Blinden.


    Grüße


    [ - Antworten - Zitieren - Direktlink - ]

    25.07.2009, 13:10 Uhr

    Holger
    Posts: 8116
    Nutzer
    Zitat:
    Original von jolo:
    Es ist echt schwierig so etwas 68000er kompatibel zu machen...
    Und ja, ich habe gerade 4 Gigabytes RAM verschwendet...

    Oder einfach nur dämlich ausgedrückt, also Du von den Werten "von 1000000000 bis 1" gesprochen hast.
    Zitat:
    Ich bin kein Profi, nur ein Einäugiger unter Blinden.
    Nur äußerst eingebildet, würde es offensichtlich besser treffen.

    mfg

    --
    Good coders do not comment. What was hard to write should be hard to read too.

    [ - Antworten - Zitieren - Direktlink - ]

    25.07.2009, 13:18 Uhr

    Holger
    Posts: 8116
    Nutzer
    Zitat:
    Original von AGSzabo:
    aber wenn ich nicht vor habe 2 versionen meines programms zu veröffentlichen ist es nicht reatsam nur 68020++ code zu verwenden..

    Häh?!
    Eben noch wolltest Du nur aus Spaß an der Freude über den Algorithmus diskutieren, jetzt geht es doch um ein Programm, das Du veröffentlichen willst?
    Jetzt entscheide Dich mal. Wenn Du ein Programm veröffentlichen willst, solltest Du wissen, welche Plattformen Du unterstützen willst.

    Wenn Du nämlich erst mal wirklich weißt, was Du wirklich willst, und Du es auch klar sagst, so dass es alle sehen können, können Dir nicht nur Einäugige helfen.

    mfg

    --
    Good coders do not comment. What was hard to write should be hard to read too.

    [ - Antworten - Zitieren - Direktlink - ]

    25.07.2009, 14:59 Uhr

    AGSzabo
    Posts: 1663
    Nutzer
    @Holger:

    > Eben noch wolltest Du nur aus Spaß an der Freude über den Algorithmus diskutieren, jetzt geht es doch um ein Programm, das Du veröffentlichen willst?

    Das ist jedenfalls kompatibel da brauchen wir uns nicht streiten. Das Programm entsteht zur freue und ist gratis, aber das macht keinen Unterschied.

    @jolo super beitrag, danke!

    --
    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 25.07.2009 um 15:00 Uhr geändert. ]

    [ - 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.
    .